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.

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

Provide an @IncrementalBuild annotation #59

Open
laeubi opened this issue Jan 10, 2023 · 2 comments
Open

Provide an @IncrementalBuild annotation #59

laeubi opened this issue Jan 10, 2023 · 2 comments

Comments

@laeubi
Copy link
Collaborator

laeubi commented Jan 10, 2023

Currently m2e allows to specify a lifecycleMappingMetadata to control how the mojo should be handeled in an incremental build: https://www.eclipse.org/m2e/documentation/m2e-making-maven-plugins-compat.html

A more convenient way would be to have an @IncrementalBuild annotation that has boolean properties runOnConfiguration, runOnBuild and runOnClean, specifying none of them, or all false, is then equivialent to ignore.

This can then be used to generate the xml automatic or even evaluated at runtime.

FYI @HannesWell

@HannesWell
Copy link
Collaborator

Sounds good.

A more convenient way would be to have an @IncrementalBuild annotation that has boolean properties runOnConfiguration, runOnBuild and runOnClean, specifying none of them, or all false, is then equivialent to ignore.

As discussed elsewhere runOnBuild maybe should be more fine-grained and be instead runOnFullBuild and runOnIncrementalBuild. The latter could be used for mojos that are expensive to execute but need to be executed more often than only once on configuration.
On the other hand such a mojo should then probably be improved to detect by itself if a full execution is really necessary and return fast if nothing is really to do. Then it could just run on incremental builds and only execute 'completely' if necessary.

This can then be used to generate the xml automatic or even evaluated at runtime.

This is similar to eclipse-m2e/m2e-core#830. If a runtime retention-policy is used we could just check for and read the annotation at runtime and avoid the need to generate a metadata-file. The would simplify building mojos that use it. And because a plugin that uses the build-context has a dependency for this artifact anyways I don't see a real reason to not use that. At least the no-additional-dependency argument does not apply here.

@laeubi
Copy link
Collaborator Author

laeubi commented Jan 22, 2023

The is actually no difference between "full" and "incremental", both are builds and a mojo should simply avoid unneeded changing of files if it detects them instead.

The point is where the dependency is evaluated, m2e must be able to read the metadata regardless of supported version and thus an XML is better suited here than a runtime annotation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants