Am 09.08.11 19:15, schrieb Max Rydahl Andersen: >> 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 I think, you rotate the the view. Maven is the tool, which m2e plug-in must be integrate. That mean, that all possibility, what you can make with mvn on the console, must be work with m2e plug-in. Or ? > > > > _______________________________________________ > m2e-users mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/m2e-users
_______________________________________________ m2e-users mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/m2e-users
