-
Notifications
You must be signed in to change notification settings - Fork 3
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
Comments
Sounds good.
As discussed elsewhere
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. |
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. |
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.htmlA more convenient way would be to have an
@IncrementalBuild
annotation that has boolean propertiesrunOnConfiguration
,runOnBuild
andrunOnClean
, specifying none of them, or all false, is then equivialent toignore
.This can then be used to generate the xml automatic or even evaluated at runtime.
FYI @HannesWell
The text was updated successfully, but these errors were encountered: