Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

m2e build is triggered by change in target folder #1275

Closed
laeubi opened this issue Feb 28, 2023 · 8 comments · Fixed by #1276
Closed

m2e build is triggered by change in target folder #1275

laeubi opened this issue Feb 28, 2023 · 8 comments · Fixed by #1276
Assignees
@laeubi
Labels
sponsored

Comments

@laeubi
Copy link
Member

laeubi commented Feb 28, 2023

I have a multi-module project where random builds are triggered, and even can result in endless build cycles.

According to the Maven Workspace Build View, this is triggered by a change in the target folder:

grafik

One observation is that, weather or not this should trigger a change, even the parent project build is triggered by its child change.

I then open a terminal and touch a random file in the target folder a build is triggered.
@laeubi
Copy link
Member Author

laeubi commented Feb 28, 2023

To narrow this down I tried to remove the parent project from the workspace but still any change in the target folder triggers a build. The build previously has had some source folders that point to a folder inside target, but configuring these to a different location still triggers the build.

@laeubi
Copy link
Member Author

laeubi commented Feb 28, 2023

I now have checked this with a simple project with only one class and no items configured.
When I compile the project once and then touch the resulting jar in the target folder, each touch results in a workspace build.

@mickaelistria
Copy link
Contributor

Is the target folder marked as derived in project metadata? I think it used to be the criterion in order to decide whether a rebuild is necessary or not.

@laeubi
Copy link
Member Author

laeubi commented Feb 28, 2023

Yes, but actually this does not make any difference. Also it is possible that resources are derived (eg. generated) but still relevant for build input ... as far as I can see currently there is no filtering at all, even if one changes a property of a folder a build is triggered, but I'm currently working on a patch.

@laeubi
Copy link
Member Author

laeubi commented Feb 28, 2023 •
edited
Loading

@mickaelistria I'm playing around a bit and found that m2e is not getting the change in the .java file but a change in the .class file! That's a bit surprising but maybe the reason why the target folder can't be excluded actually as otherwise m2e won't get a trigger at all ... I'll try to debug this a bit more in detail.

EDIT Strike that, the java change is triggering it was just lost in my debug output between the lines ...

@HannesWell
Copy link
Contributor

I encountered that problem as well which resulted sometimes in endless builds for me, because the change in the target-folder done by a executed mojo triggered a new build.
But believed one reason was that the Eclipse-resources/builder did not know that the executed mojo did that change (e.g. because it didn't use the build-context). So maybe a refresh of the project after the m2e-builder had completed (wherever the build-context is read) could help here as well?

@laeubi
Copy link
Member Author

laeubi commented Feb 28, 2023

I think both should be combined, because even if someone else outside eclipse modifies a file in the target this should normally not trigger a build, I'll try to provide a PR for this and then we can check how it works out, there are just too many (legal) ways a mojo can write some stuff into the target folder that do not require a build, the target holds the result of the build so if the result triggers a build again, something is definitely wrong ...

I have one case that is the (e.g. maven-compiler-plugin ) that plugins put generated resource in the target folder, I can cover this case, but actually think that even in this case one should ignore it, because it is a direct consequence of the build-execution and any change here will be overwritten by the triggered build...

laeubi added a commit to laeubi/m2e-core that referenced this issue Feb 28, 2023
@laeubi
Only trigger (incremental) builds if there are relevant changes
f21fd36 
Currently any file change in a project can trigger a rebuild of that
project, even if it is from the build-output or from child modules. This
can produces "endless" loops of the build and produces a lot of build
rush if automatic refresh is activated for the workspace or resources
are refreshed on access. On the other hand, without autorefresh some
changes are never detected.

This changes the following:
- check if a delta only contains irrelevant deltas and then do not
trigger an incremental maven build
- refresh the whole project first to discover new files generated
- if auto refresh is enabled, do not manually refresh but use the native
refresh events

This can considerably reduce the number of rebuilds happening.

Fix eclipse-m2e#1275
@laeubi laeubi mentioned this issue Feb 28, 2023
Merged
laeubi added a commit to laeubi/m2e-core that referenced this issue Feb 28, 2023
@laeubi
Only trigger (incremental) builds if there are relevant changes
b78de4c 
Currently any file change in a project can trigger a rebuild of that
project, even if it is from the build-output or from child modules. This
can produces "endless" loops of the build and produces a lot of build
rush if automatic refresh is activated for the workspace or resources
are refreshed on access. On the other hand, without autorefresh some
changes are never detected.

This changes the following:
- check if a delta only contains irrelevant deltas and then do not
trigger an incremental maven build
- refresh the whole project first to discover new files generated
- if auto refresh is enabled, do not manually refresh but use the native
refresh events

This can considerably reduce the number of rebuilds happening.

Fix eclipse-m2e#1275
laeubi added a commit to laeubi/m2e-core that referenced this issue Feb 28, 2023
@laeubi
Only trigger (incremental) builds if there are relevant changes
b45bb23 
Currently any file change in a project can trigger a rebuild of that
project, even if it is from the build-output or from child modules. This
can produces "endless" loops of the build and produces a lot of build
rush if automatic refresh is activated for the workspace or resources
are refreshed on access. On the other hand, without autorefresh some
changes are never detected.

This changes the following:
- check if a delta only contains irrelevant deltas and then do not
trigger an incremental maven build
- refresh the whole project first to discover new files generated
- if auto refresh is enabled, do not manually refresh but use the native
refresh events

This can considerably reduce the number of rebuilds happening.

Fix eclipse-m2e#1275
laeubi added a commit that referenced this issue Feb 28, 2023
@laeubi
Only trigger (incremental) builds if there are relevant changes
8e5cd49 
Currently any file change in a project can trigger a rebuild of that
project, even if it is from the build-output or from child modules. This
can produces "endless" loops of the build and produces a lot of build
rush if automatic refresh is activated for the workspace or resources
are refreshed on access. On the other hand, without autorefresh some
changes are never detected.

This changes the following:
- check if a delta only contains irrelevant deltas and then do not
trigger an incremental maven build
- refresh the whole project first to discover new files generated
- if auto refresh is enabled, do not manually refresh but use the native
refresh events

This can considerably reduce the number of rebuilds happening.

Fix #1275
@laeubi laeubi changed the title m2e build is triggered by chnage in target folder m2e build is triggered by change in target folder Mar 1, 2023
@laeubi laeubi self-assigned this Mar 1, 2023
@laeubi
Copy link
Member Author

laeubi commented Mar 1, 2023

The fix for this issue was gently sponsored by ivv GmbH.

@snjeza snjeza mentioned this issue Mar 10, 2023
Open
@kohlschuetter kohlschuetter mentioned this issue Dec 20, 2023
Closed
kohlschuetter added a commit to kohlschuetter/m2e-core that referenced this issue Dec 20, 2023
@kohlschuetter
Fix "m2e plugin sometimes 'loses' resources" (eclipse-m2e#1511)
b1b4159 
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
kohlschuetter added a commit to kohlschuetter/m2e-core that referenced this issue Dec 20, 2023
@kohlschuetter
Fix "m2e plugin sometimes 'loses' resources" (eclipse-m2e#1511)
70a58f7 
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
@kohlschuetter kohlschuetter mentioned this issue Dec 20, 2023
Merged
laeubi pushed a commit that referenced this issue Dec 22, 2023
@kohlschuetter
Workaround for "m2e plugin sometimes 'loses' resources"
2ae34a5 
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
@OLibutzki OLibutzki mentioned this issue Mar 11, 2024
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@laeubi laeubi

Labels
sponsored
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Only trigger (incremental) builds if there are relevant changes laeubi/m2e-core
3 participants
@mickaelistria @laeubi @HannesWell