> 1. Maven plugin authors need to worry about which IDE their users use,
> they need to provide explicit Eclipse integration along with their
> plugin. It feels wrong that when writing a Maven plugin I need to
> worry about IDEs (rather than simply Maven itself), an indication that
> m2e has taken the wrong path here. Where plugins are concerned, m2e
> appears to effectively no longer integrate with Maven, it needs an
> additional 'integration layer' to be written across the plugin
> universe. I'm confused and amazed by this design decision.
As long as IDE's and build tools doesn't do exactly the same thing in all cases
this has always been and always will be a concern.
(if they did - why are there more of them ? :)
Maven, Netbeans, eclipse and intellij already have different behaviors - it might just not
be completely obvious to you in daily life but they do.
it is something I agree with the m2e team on that users should be made aware of - they
need to take a conscious choice if they want to actually have maven execute the maven plugin (
with all the possible side effects that will have) or ignore it.
Previously M2e just executed it which resulted in countless cases of performance bugs
and very hard to find bugs because the maven plugin was not considering the much more incremental
environment and concurrent aspect of an IDE.
So something had to be done - m2e dev's went all out with putting Error markers and ignore the plugins
they did not have info about (I would have made it Warning markers and ignore and I believe that would
make people understand this issue much better).
> 2. Projects using Maven need to add IDE-specific (Eclipse-specific)
> configuration into their pom, or worse individual developers that work
> on a project need to customize their local sources before Eclipse can
> even build a Maven project.
> Bug 350414 should go some way to address
> this if fixed right, but no doubt Eclipse will still allow the
> lifecycle mappings to the pom where they really do not belong.
I agree it should be an option - but I do not agree they they don't belong in the pom.
It's a great way of sharing the settings without introducing more files into your SCM and
it doesn't affect your normal maven setup.
> In the
> short term (where the POM is the only place these mappings are
> supported), I believe Indigo/m2e is not viable for many, many
> projects, since adding IDE specific configuration will be deemed
> unacceptable by project owners.
Please note that maven still build your project even with these error markers.
it just doesn't execute the plugins for you - if it did then we would be back to having
all the problems that made m2eclipse unstable before.
> Is there any chance that for Indigo SR1 or SR2 the m2e dev team will
> revisit this lifecycle integration in a fundamental way that will
> address these problems? Maybe it's possible to learn from the Maven
> integration done by other IDEs?
If you know of an IDE that does it better let me know.
Last I checked netbeans just delegate to Maven == SLOW!
And intellij reads some parts of the metadata and ignores the rest == Hiding the errors.
(this was last year - if things has changed I would love to hear)
/max
http://about.me/maxandersen
