What will happen if several m2e extensions provide alternative/competing
support for the same project packaging type or plugin execution? This
question came up several times already and our answer so far was "not
supported".
While working on m2e extension discovery implementation, I've realised
that proper implementation of this "not-supported" approach ends up
quite involved. Implementation basically needs to detect conflicts among
all new and installed m2e extension, which is not easy.
Another major limitation of "not-supported" approach in my opinion, is
that it is not possible to import project with explicit lifecycle
mapping configuration in pom.xml, if it happens to conflict with
currently installed m2e extensions. Again, we need to detect the
conflict and basically do not allow the import. Again, not easy to
implement. It will also be rather "surprising" to the user and not in a
good way.
I think m2e should provide proper support for alternative/competing
extensions and [1] explains how I think we can do it. Development effort
should be about the same as providing proper "not-supported"
implementation, so I see no reason to stick with inferior approach.
What do you think? Any objections I schedule this work for M7?
[1]
https://docs.sonatype.org/display/M2ECLIPSE/multiple+mappings+for+the+same+packaging+type+or+maven+plugin+execution--
Regards,
Igor
_______________________________________________
m2e-dev mailing list
m2e-dev@xxxxxxxxxxxhttps://dev.eclipse.org/mailman/listinfo/m2e-dev
