m2e plugin sometimes "loses" resources - using snapshot 2.1.201.20230809-1423 #1511
Comments
|
@laeubi anything we can help on getting any progress on this? |
|
@tarioch It actually should have been improved by the last m2e eclipse release, but we can only try to make it less often as the underlying cause is here: but it hasn't gotten much attention from the maven people yet (and I'm not a maven committer). |
|
Beside that, sponsoring is a good way to get specific issues fixed, so if this is crucial to your business and you likes to speed up the development of m2e in general a sponsoring would allow me to assign more time-slots to bug fixing or contact me for an individual contract for example fixing a specific issue, m2e is sadly manly drive by volunteers working on their (spare) free time so it often takes some time if no one can dedicate time or money. |
|
Thanks for your response. Unfortunately even with latest version it still is still very, very bad. Is there a fundamental change why this issue happens since 2022-12? I haven't seen it before. |
|
Did do some more testing, now used the plain eclipse java installation from eclipse and a very tiny project (empty pom file, one empty class and one dummy resource). 2022-12/m2e 2.1.2Adding/removing a dependency to the pom.xml doesn't impact the resources, classes don't seem to get recompiled, resources are untouched 2023-03/m2e 2.2.1 (same behavior also in latest 2023-09)Adding/removing a dependency to the pom.xml does seem to trigger a rebuild, afterwards the resource file is gone and the class file has a newer timestamp Any idea what the big change in m2e 2.2 was that changed this behavior? From the release notes I saw that there was a change to execute plugins by default in incremental builds and I tried with the setting changed to ignore, but it's still the same behavior. |
I've downgraded the version to 2.1.2, and it is as normal as you said. |
I already analyzed that, the problem is that resource-mojo assumes that if a resource never gets deleted from the output without getting it as a "delta" what is not always true and m2e no longer perform such updates because it lead to infinite build cycles, I already proposed a fix but it got less interest and I'm currently not have time to push it forward: so it does not really help to complain about m2e "not coping" because m2e does never has nor do copy anything... |
|
If the maven-resources plugin cannot be fixed. |
It can be fixed, see PR I just don't have had the time yet to look into the test failure what might just be a changed assumption. I now also created to supply a more modern API for file changes. |
THis would require to disable the plugin completely and rewrite all its functionality from scratch... |
I can confirm that downgrading to 2.1.2 solves the issue, but this is not a suitable solution in the long run. m2e 2.1.2 is not compatible to Java 21, so this issue is a blocker for upgrading to the latest Java LTS version.
I understand that there was a motivation for fixing the infinite build cycle, but at least for our projects the change made the situation even worse. As we have a lot of resources, some of them seem to be midding on the classpath randomly (I am quite sure it's not random, but from an end-user's perspective it feels like that). I understand that you propose to change the scanner in Maven Filtering, but until that issue is fixed, it would be helpful to get back the old behaviour in order to make m2e useable again. Maybe you could provide a configuration option to switch the behaviour, so the users can decide for the lesser of two evils:
|
|
That is not really suitable, m2e is not responsible for other maven plugins, if these plugins have bugs these need to be addressed (but not at m2e side). If we install any workaround this will mean we need to maintain it forever because no one will ever fix the root problem if it "just works for me". |
|
If this is crucial to someones business and likes to speed up the development in that area a sponsoring would allow me to assign more time-slots particular issue. In the meanwhile I'll try to trigger the maven devs if we can get some speedup on this (i'm not a committer on that project): |
|
@laeubi It looks like MSHARED-1285 was merged an hour ago. How can we test that this fix is effective? |
|
@laeubi I'm still seeing errors with MSHARED-1285. I'm able to verify that the new code is called, but it looks like something is deleting files from the target directory after the check returns with a "file is up to date" response. And that deletion is not detected by Eclipse, even if "Refresh using native hooks or polling" is on (presumably because it's an output directory?) By manually preventing the file from being deleted (using " My suspicion is that "is up to date" check is run too early, or the "Maven Project Builder" doesn't take deletions from the "Java Builder" into account. Reordering the "Java Builder" and the "Maven Project Builder" has no effect. (Disabling the "Java Builder" has an effect but I guess that's undesirable) |
You need a local build or wait for a new release (not sure if there are snapshot builds), then add an additional dependency to the resources plugin, but I suppose you already have found out :-)
Deletions are cached until the next change in some file if only the output folder is affected, usually it is like this:
Looking at the |
|
@laeubi Reordering the builders such that "Maven Builder" comes first (then restarting) has the effect that deletions aren't even triggering the code in MSHARED-1285. I verified this by
|
|
@laeubi Could it be that your change 8e5cd49 (for #1275) is at play here? I think this check would simply ignore deletions in |
As explained above, deletions in |
|
@laeubi I can confirm that removing the I'm triggering the bug by adding/removing a dependency in pom.xml. I don't see any problems after removing that check. |
The please add a test-case to m2e so it can be analyzed
It can produce endless build cycles if a mojo constantly modifies a file during its build |
I'm not sure how to distill this Eclipse problem into a runnable test case, maybe you could help me with that. I'm literally just right now picking up how to build these things to alleviate the pain as an Eclipse user, not an Eclipse developer.
Checking only for missing files/deletions in an output folder on the classpath/modulepath should be sufficient. I think the problem of endless build cycles can be avoided by limiting the number of cycles it executes to 2. |
You should be able to copy an existing test-case from here: It usually is always the same:
In general the output folder is nothing that m2e has to be concerned as it is the property of the build cycle, nothing there should result in an (incremental) build as it is the output not the input of a build.
You can't know that it is triggered by the previous one and having users to restart eclipse after the second change they made in their workspace seems not suitable ;-) |
I don't understand what you mean by that. What restart?
You could say m2e should be concerned because that change in February, which, for what it's worth, didn't include any tests, broke existing working behavior, costing many users countless hours of frustration. |
fbricon
changed the title
Contributions are always welcome especially trivial ones ;-)
There is not a single test failing so there is no "existing behavior" only something that sometimes worked also know as "undefined behavior". That's why I said if you can reproduce a problem with a simple add/remove dependency there should be a test added so we can define the desired behavior even though this seems to be a different bug, that is that m2e does not triggers a full build when dependencies change what is never an incremental change as then everything could change in any way. |
The Java Builder may delete files from the project output directory that need to be re-created by the m2e Maven Builder. With commit 8e5cd49 (a fix for eclipse-m2e#1275), any changes to the project output directory were ignored, leading to unexpected errors when running an application after modifying the project POM: resources were missing from the target classpath, leading all sorts of unexpected program behavior. This change allows marking these changes as relevant, as long as the following conditions are met: - The expected resource no longer exists (i.e., it was deleted by another builder, plugin or outside process) - The modification applies to a resource in the classes or test-classes folder (i.e., outputLocation/testOutputLocation) eclipse-m2e#1511 eclipse-m2e#1275
The Java Builder may delete files from the project output directory that need to be re-created by the m2e Maven Builder. With commit 8e5cd49 (a fix for eclipse-m2e#1275), any changes to the project output directory were ignored, leading to unexpected errors when running an application after modifying the project POM: resources were missing from the target classpath, leading all sorts of unexpected program behavior. This change allows marking these changes as relevant, as long as the following conditions are met: - The expected resource no longer exists (i.e., it was deleted by another builder, plugin or outside process) - The modification applies to a resource in the classes or test-classes folder (i.e., outputLocation/testOutputLocation) eclipse-m2e#1511 eclipse-m2e#1275
|
@laeubi Please take a look at my pull request. I hope this works for you. For others trying to validate this:
|
... addressing reviewer concerns
|
I just apply @kohlschuetter workaround:
So it « works ». I read considerations about how the bug is fixed. I do not have enough insight at the time to judge the current proposal. |
The Java Builder may delete files from the project output directory that need to be re-created by the m2e Maven Builder. With commit 8e5cd49, any changes to the project output directory were ignored, leading to unexpected errors when running an application after modifying the project POM: resources were missing from the target classpath, leading all sorts of unexpected program behavior. This change allows marking these changes as relevant, as long as the following conditions are met: - The expected resource no longer exists (i.e., it was deleted by another builder, plugin or outside process) - The modification applies to a resource in the classes or test-classes folder (i.e., outputLocation/testOutputLocation) See #1511 See #1275
It fixes the problem that when the output folders are deleted but do not fixes for example this reproducer: so one still need the MSHARED-1285 bugfix as well for cases where the output folder is not deleted, and we would need a testcase for what is described by @kohlschuetter and @lalmeras as a test-case to ensure it works in the future. |
|
is there any update on this regression bug? I continue to experience these types of issues since this bug was first reported. the only solution seems to be remove the app from 'Modules' and adding it back again to get Eclipse/Spring to redeploy.
|
|
Which version of m2e are you using? I don't believe there's been an actual release since the fix was merged, but I've been using the nightly builds from https://download.eclipse.org/technology/m2e/snapshots/latest/ for a while (M2E - Maven Integration for Eclipse 2.4.300.20240123-0523 at the moment) and do not experience this bug anymore. Before the fix I had been using the workaround mentioned here with success. |
|
thanks - so far, so good with the snapshot.
…On Wed, Jan 24, 2024 at 4:04 AM Pierre-Charles David < ***@***.***> wrote:
Which version of m2e are you using? I don't believe there's been an actual
*release* since the fix was merged, but I've been using the nightly
builds from https://download.eclipse.org/technology/m2e/snapshots/latest/
for a while (M2E - Maven Integration for Eclipse 2.4.300.20240123-0523 at
the moment) and do not experience this bug anymore.
Before the fix I had been using the workaround mentioned here
<#1585 (comment)>
with success.
—
Reply to this email directly, view it on GitHub
<#1511 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAJDHBY6TPZRJWXJC577CITYQDFDRAVCNFSM6AAAAAA3SLMJCGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMBXGY4DKNJXGM>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
We plan to perform a release soon, probably at the weekend. |
|
I think I am suffering from similar symptoms but under conditions I haven't been able to explain, but most certainly while rebuilding chains of modules as part of POM changes. |
|
M2e has a new release where, together with apache/maven-filtering#77 this should now fix the problem. |
In some cases, the resources are deleted from the target folder and not copied over again.
e.g. one case I encounter is, if I do any change in the pom file, all my resources disappear until I touch any of the resources or java files.
This is the split up from the issues which are still existing in snapshot 2.1.201.20230809-1423
See #1302 for more details.
Reproduction: #1478
The text was updated successfully, but these errors were encountered: