On the m2e-users list (for maven / Eclipse users), it discusses some fairly fundamental issues with using the new m2e plugin in the Eclipse 3.7 distribution. Here's the post...
-Marshall -------- Original Message -------- Subject: [m2e-users] Long term outlook for 'M2E plugin execution not covered' Date: Sun, 7 Aug 2011 16:01:00 +0100 From: Joe Littlejohn <[email protected]> Reply-To: Maven Integration for Eclipse users mailing list <[email protected]> To: [email protected] Hi all, I recently upgraded to the new m2e release that has arrived with Eclipse Indigo and I'd like to give some feedback. Like many users attempting to use m2e, I've had problems with the behaviour described here: http://wiki.eclipse.org/M2E_plugin_execution_not_covered Firstly, I found it a bit disappointing to arrive in Eclipse Indigo with my first Maven project imported, only to be confronted by a broken build that had to be fixed by heading to Google and tracking down a somewhat confusing workaround. For devs working in organisations that build many, non-trivial Maven modules, hitting this problem early on is inevitable and the experience is not great. Now that I think I grok the above linked wiki page, I'm very uncomfortable with the implications that it has for m2e users and Maven plugin developers. We're now in a situation where: 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. 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. 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. These problems are really bad news for organisations that maintain many hundreds of Maven modules. It seems like we're in a big mess at the moment and one that will force users to stick with Helios & m2eclipse 0.12. I fear that a fundamentally harmful design choice has made m2e (and therefore Eclipse) less tenable for Maven users. The case for migration to Netbeans or Intellij has just been given some solid ammunition. I'm afraid I don't have an alternative solution to discuss with m2e-dev since I'm not familiar with the internals of m2e. As an end user though, I feel there are some big problems here. 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? I hope this doesn't sound like an attack. No doubt the latest version of m2e brings a whole load of benefits that I haven't yet had a chance to experience, and for those I'm really grateful to the development team for the effort put in. I'd love to get the benefit of those improvements, but problems I've described here are show-stoppers for me and probably many others. Does anyone else feel similarly? Cheers Joe _______________________________________________ m2e-users mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/m2e-users
