Spring Tool Suite 17 with maven no longer copies application.properties file to the target folder

[marcgemis]

Describe the bug
When you create a new Spring Boot project (2.76, Maven, Java 17) with Spring Web an application.properties file gets created. When you edit this file, e.g. add server.port=8888 and save the file, the file never appears in the target folder of the project.
This also means that the web application still starts at the default port 8080.

There is no problem with the same project is created with gradle.

Platform MacOS Monterey 12.5.1 Apple M1 chip - Eclipse STS 17.0

To Reproduce
See above

Problem does not occur in STS 14

A non-working maven project, and a working gradle project
sounds-of-animals-maven.zip
sounds-of-animals.zip

[martinlippert]

I can reproduce this and I think this is a problem with the m2e integration in Eclipse (since I can reproduce this with Eclipse 2022-12 RC1 JEE package as well), therefore I reported this issue via eclipse-m2e/m2e-core#1148 to the m2e project.

[martinlippert]

Here is the issue from the m2e project where this got fixed: eclipse-m2e/m2e-core#1150 - now waiting for a new release of m2e to be published that includes this fix.

[marcgemis]

thanks for keeping me updated

[martinlippert]

In case you want to try the fix early, you can add the m2e snapshots update site to the preferences (Preferences -> Install/Update -> Available Update Sites, then add https://download.eclipse.org/technology/m2e/snapshots/latest/) and run a Check for Updates.

Feel free to uncheck the JustJ JRE update, but keep everything else selected and run the update. It includes the fix for this issue.

[martinlippert]

Unfortunately the workaround doesn't seem to work anymore due to a new dependency being required from the latest m2e snapshot builds. I am looking into this to see what we can do here. In the meantime, run a regular maven build on the command line or via the Run As -> Maven Install menu item whenever you change those resource files.

[CrisLi]

this issue is still here, is there any hotfix?

[martinlippert]

@CrisLi The workaround described above (running stuff manually) should work, the fix for the underlying issue is implemented in the corresponding component (the Maven Integration, m2e) and we are waiting for a new release of m2e to include this fix (I guess on-time for the next major Eclipse release, coming in mid March).

In the meantime, we have fixed the issues that were preventing us from installing the latest m2e snapshot CI builds, that works again with our latest snapshot CI builds. So if you would like to, you could go to https://dist.springsource.com/snapshot/STS4/nightly-distributions.html, download and install this latest CI build (on top of Eclipse 4.26 or 4.27, whatever you prefer) and then install the latest m2e snapshot to it (as described above). That would result in an STS environment with the m2e fix included, but would also mean to run on the latest CI builds of STS as well as m2e.

[CrisLi]

thanks for the reply. let me try the workaround

[martinlippert]

Closing this from the Spring Tools perspective now, the updates to m2e will be included on the upcoming 4.18.0 release (from what I can see at the moment).

[cypher256]

Note: To be supported in Eclipse SimRel 2023-03
eclipse-m2e/m2e-core#1279

[arimeyer]

I'm still seeing the problem, getting:

Exception in thread "main" org.springframework.beans.factory.BeanDefinitionStoreException: IOException parsing XML document from class path resource [applicationContext.xml]
at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:342)
at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:310)
at org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:184)
at org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:220)
at org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:191)
at org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:253)
at org.springframework.context.support.AbstractXmlApplicationContext.loadBeanDefinitions(AbstractXmlApplicationContext.java:128)
at org.springframework.context.support.AbstractXmlApplicationContext.loadBeanDefinitions(AbstractXmlApplicationContext.java:94)
at org.springframework.context.support.AbstractRefreshableApplicationContext.refreshBeanFactory(AbstractRefreshableApplicationContext.java:130)
at org.springframework.context.support.AbstractApplicationContext.obtainFreshBeanFactory(AbstractApplicationContext.java:672)
at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:554)
at org.springframework.context.support.ClassPathXmlApplicationContext.(ClassPathXmlApplicationContext.java:144)
at org.springframework.context.support.ClassPathXmlApplicationContext.(ClassPathXmlApplicationContext.java:85)
at Driver.main(Driver.java:11)
Caused by: java.io.FileNotFoundException: class path resource [applicationContext.xml] cannot be opened because it does not exist
at org.springframework.core.io.ClassPathResource.getInputStream(ClassPathResource.java:211)
at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:333)
... 13 more

I reverted to 4.16.1, and the problem is gone.

[martinlippert]

@arimeyer Can you attach a small sample project that reproduces this issue? And can you double check which version of the m2e plugins you have installed in your environment that doesn't work? The version that are ship and which should include a fix for this is: org.eclipse.m2e.core_2.0.7.20230307-1553

[arimeyer]

Hi @martinlippert -- will try to do so this weekend. Best, Ari

[pcdavid]

FYI, I'm on STS 4.18.0 with org.eclipse.m2e.core 2.0.7.20230307-1553 and am still seeing the issue. Doing a full build (Project > Clean... > Clean all projects) seems to fix it, but it tends to re-appear once in a while.

[martinlippert]

FYI, I'm on STS 4.18.0 with org.eclipse.m2e.core 2.0.7.20230307-1553 and am still seeing the issue. Doing a full build (Project > Clean... > Clean all projects) seems to fix it, but it tends to re-appear once in a while.

Hey @pcdavid, I also have a colleague who reports the same, but I am not able yet to reproduce it. Do you have a sample project and/or a few steps how to reproduce this. The steps that I tried don't trigger the issue yet. Many many thanks for your help!

[pcdavid]

I don't understand yet what triggers it but I'll comment here if I find more.

[martinlippert]

I don't understand yet what triggers it but I'll comment here if I find more.

That would be great, looking forward to hearing more details from your side. Also in case you have a project that you can share, let us know.

[pcdavid]

Also in case you have a project that you can share

Well, in my case it's on https://github.com/eclipse-sirius/sirius-components, but that's 320 kSLOCs of Java across 57 Maven modules, so as far as a minimal repro case as can be...

[pcdavid]

So, I now have a much simpler scenario to reproduce. I don't think it's possible to do simpler.

1. Still using a unmodified STS 4.18.1 (this time under Ubuntu 23.4 instead of Fedora 38, but I don't think it's relevant).
2. Import in the workspace the simplest demo project created from start.spring.io (attached for convenience).
3. Make sure Eclipse/STS is in automatic build mode.
4. Watch the project's output folder (demo/target/classes).
5. Open the project's pom.xml.
6. Initially (00:04s in the video), everyhting is fine. The output folder contains META-INF, application.properties, and the com folder with the main .class file.
7. Make a change in the POM which breaks its syntax. Save.
8. We see a rebuild hapening, with only the com folder available (00:15s).
9. Fix the typo in the POM. Save.
10. New rebuild. Initially we see all 3 entries (META-INF, application.properties and com) appearing (00:21s), but then META-INF and application.properties disappear in the final (broken) state.

We're back to a valid state where everything compiles without error, but META-INF and application.properties are missing from the output folder.

Not shown on the video: doing a "Project > Clean... > Clean all projects" afterwards fixes the issue (in this very simple case).

simplescreenrecorder-2023-07-17_16.23.18.mp4

Sample project used: demo.zip

The m2e issue eclipse-m2e/m2e-core#1150 linked above mentioned that it may be related to the presence of the .mvn folder. It's present in the demo.zip attached as start.spring.io creates it, but I also tested without the folder and get the same result.

[pcdavid]

Unsurprisingly, I reproduce the issue with the scenario above on a plain "Eclipse IDE for Java Developers 2023-06 (4.28.0)", so it's not related to an STS-specific component.
I guess this should be moved to m2e.

[BoykoAlex]

@pcdavid Thanks very much for the simpler instructions to reproduce this issue. I have attempted a JUnit test for this in M2E-Core. It has a few Thread.sleep(...) calls in it but hope it'd be enough for M2E team to take over this. See eclipse-m2e/m2e-core#1302 (comment)

[BoykoAlex]

This is the m2e issue we are waiting on to be fixed: eclipse-m2e/m2e-core#1511

[BoykoAlex]

@martinlippert I've installed the latest M2E 2.5.0 which came out on 2023-11-27 and I still observe the issue. Moving to 4.21.1

[pcdavid]

There's some activity on apache/maven-filtering#77 (comment) which seems to be the root cause. No idea how long it would take, once merged there (and assuming this indeed fixes the issue) to be available in STS. It looks like it would need a new Maven release?

It's been reported multiple times on m2e (eclipse-m2e/m2e-core#1585 and eclipse-m2e/m2e-core#1511 for example).
I've not tested it yet, but this comment mentions that a workaround is "to have a Maven launcher in Eclipse running "resources:resources" each time before launching my software."

[goodale]

@pcdavid any update on this issue? the stated workaround is untenable for enterprise projects with many applications in your workspace

[pcdavid]

A fix for the (potential) underlying issue in Maven has just been merged: apache/maven-filtering#77.
There are exchanges ongoing on eclipse-m2e/m2e-core#1511 to see how this can be tested in the context of m2e and confirm.
Not sure if this will require a new release of Maven Filtering and/or Maven itself.

[pcdavid]

A potential fix has just been merged in m2e itself via eclipse-m2e/m2e-core#1629
It can be tested by updating m2e from https://download.eclipse.org/technology/m2e/snapshots/latest/ and getting org.eclipse.m2e.feature 2.4.300.20231222-1142 (or more recent).

[martinlippert]

Thanks a lot @pcdavid for this update, that sounds indeed quite promising. I will include the m2e snapshot update site in our builds, so that we could get a few nightly builds of STS that include this fix right away for further testing here. Will keep you posted here once those builds are around.

[martinlippert]

Builds that include the m2e fix are available now from here:
https://cdn.spring.io/spring-tools/snapshot/STS4/nightly-distributions.html

It is included in builds based on Eclipse 2023-12 (e4.30) as well as the early access builds for Eclipse 2024-03 (e4.31).

[martinlippert]

@pcdavid Do you think that this fixes the issue for all the cases you observed?
@BoykoAlex Probably worth a try to double check from your end as well

[pcdavid]

@pcdavid Do you think that this fixes the issue for all the cases you observed?

I have not experienced the bug since I updated, but I've not used STS much these last few days and the bug was not systematic. It looks good, but it's difficult to be sure.

[martinlippert]

@pcdavid Do you think that this fixes the issue for all the cases you observed?

I have not experienced the bug since I updated, but I've not used STS much these last few days and the bug was not systematic. It looks good, but it's difficult to be sure.

Thanks for the update, much appreciated. Let's keep an eye on this for a little longer before we finally close this item here.

[OLibutzki]

As this comment states there is some relationship to apache/maven-filtering#77, too.

So maybe we need a maven-filtering release including apache/maven-filtering#77 before this issue can be closed?

[BoykoAlex]

@martinlippert are we moving this to 4.22.0 to include new eclipse release with new m2e release?

[martinlippert]

Yes, since we don't have a new release of m2e yet that includes this and we will not ship the Spring Tools 4.21.1 release with an snapshot version of m2e, we will move the target milestone for this to the 4.22.0 release.

If you would like to get this into the upcoming 4.21.1 release, please install the latest m2e milestone manually into the Spring Tools distribution.

[pcdavid]

m2e has just released a version with a fix on their side: eclipse-m2e/m2e-core#1511 (comment)
It looks like a complete fix of the underlying problem will also require a new release of maven-filtering with apache/maven-filtering#77 (which has been merged), but personally I've been using m2e snapshots for a while and do not see the bug anymore.

[martinlippert]

Awesome, thanks a lot @pcdavid for the continuous feedback here, much appreciated. With that, I will close this item and mark it as solved for now. We will include the m2e 2.6 release in our upcoming Spring Tools 4.22.0 release.