-
Notifications
You must be signed in to change notification settings - Fork 115
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 Maven-Plugin to generate M2E lifecycle-mapping-metadata #830
Comments
The specification how a Mojo should be treated by M2E (ignored, executed, ...) could also be done via a corresponding annotation in the mojo-class. |
For my work on eclipse-tycho/tycho#945 I created the following very simple
|
If you like to do this a bit less "hacky" all maven plugins contain a |
Thank for that hint. Yes if this becomes reality I already thought that the information about the available goals has to be retrieved from a more reliable source, just like that. This also makes it simpler. In general, what do you think about the suggested alternatives to use annotations (that are maybe even retained at runtime)? Besides that I could imagine that some Plug-in developers don't want to 'pollute' their plug-in code with IDE specific annotations and only want to specify something like the lifecycle-mapping 'externally' in the pom. |
Annotations are great, but I think we still need the XML because loading the XML is easy but loading the class itself might becomes problematic. also if we choose to retain them in the runtime, we enforce plugins to keep a runtime dependency on the annotations (just keep in mind that Maven plugins are not only executed inside m2e). So I think the best would be to have class or source retention policy. Given that coding all that stuff is quite heavy, it might be a better alternative to write a maven-plugin instead that maybe hooks at the generation of the About DS: Just keep in mind that loading a resource is always possible, while loading a class potentially would activate the bundle if it has |
OK, yes that makes sense. Then we should stick with the XML. |
Isn't a simple annotation processor enough? I don't think it needs a full-blown Maven plugin for that. But in general a great proposal. |
Are you reffering to something like this?
I have not yet done something like this, but ist sounds very promissing. Is it correct that we then can implement the processor in the same Maven artifact like the annotations and everything is then Just picked up automagically for a consumer? The only blocker for this is that we are not yet publishing M2E to Maven-Central. |
Is there already an annotation model existing for lifecycle mapping if we want to implement an annotation processor for those? |
Not that I now. In fact IT IS part of this proposal to create one. |
For Plug-in developers that want to make their Maven plugins 'M2E-ready' it would be convenient to provide a Maven Plugin to generate a
META-INF/m2e/lifecycle-mapping-metadata.xml
automatically during the build for all Mojos of the plug-inThis plugin should
META-INF/m2e/lifecycle-mapping-metadata.xml
automatically with proper contentI think the most 'difficult' part at the moment is that M2E does not yet publish to Maven-Central. We only publish that plugin, but I think it might be beneficial for m2e in general to be published to Maven-Central. With the work being done for Eclipse-Platform that task should become simpler.
The text was updated successfully, but these errors were encountered: