Bugzilla – Full Text Bug Listing
| Summary: | Many errors, some unresolvable, when importing sources with M2E | ||||||
|---|---|---|---|---|---|---|---|
| Product: | z_Archived | Reporter: | Peter Lynch <peterlynch.ca> | ||||
| Component: | m2e | Assignee: | Project Inbox <m2e.core-inbox> | ||||
| Status: | CLOSED INVALID | QA Contact: | |||||
| Severity: | major | ||||||
| Priority: | P3 | CC: | igor, joelittlejohn | ||||
| Version: | unspecified | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Mac OS X - Carbon (unsup.) | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Peter Lynch
Created attachment 191504 [details]
Sample of numerous errors
Closing as INVALID as m2e behaves as designed even though this may not match user expectations. We have reworked the way m2e maps Maven project configuration and build lifecycle to Eclipse workspace in 0.13 and now m2e requires explicit knowledge about all Maven plugins referenced by the project. This means there is no single generic change we can make in m2e to solve all error makers you see, but we hope that m2e development team and user community will build library of Maven plugin support so the list of problems new users see will shrink over time and eventually disappear completely. To help this I suggest you create separate bugzilla record for each "non covered" Maven plugin goal your projects use, provide an example project and describe desired behaviour when this project is imported in m2e workspace. In the meantime, you can permanently suppress these error markers in pom.xml using associated quick-fix. Igor, is there any current bug report or enhancement request currently open that covers fixing the lifecycle problems described here: http://wiki.eclipse.org/M2E_plugin_execution_not_covered ? It seems like the 'by design' behaviour you describe is just not a satisfactory solution to this problem. We're now in a world in which: 1. Maven plugin authors need to worry about which IDE their developers use, they need to provide explicit Eclipse integration along with their plugin. It feels wrong that Maven plugins need to worry about IDEs, an indication that m2e has taken the wrong path here. 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. There are thousands of Maven plugins in use across the globe, does explicit m2e integration work need to be done for each one? 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. This is the kind of headache that awaits Eclipse users that upgrade to Indigo: http://stackoverflow.com/questions/6352208/how-to-solve-plugin-execution-not-covered-by-lifecycle-configuration-for-spring This is really bad news for organisations that maintain many hundreds of Maven modules. 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. m2e-dev is the place to discuss possible alternative approaches to integrating maven and eclipse. If somebody comes up with a solution that allows generic integration m2e developers will be more than happy to help with the implementation. |