Difference between revisions of "M2E project conversion enhancements"

Revision as of 14:46, 5 November 2012

Here, we discuss possible enhancements to the Eclipse to Maven conversion mechanism in m2e. Feel free to add other topics and more importantly, links to corresponding Bugzilla tickets :

Support extra configuration

• New conversion participants must extend the AbstractProjectConversionParticipant
• Currently the JavaProjectConversionParticipant only supports a single java source folder (as well as a single test source folder). Multiple source folders support in maven requires the use of the build-helper-maven-plugin. This plugin is only supported in m2e via Sonatype's m2eclipse-buildhelper plugin, which is not part of the Eclipse Foundation. As a consequence, multiple source folders support should be implemented at the m2eclipse-buildhelper level. Need to open a github issue
• Initially, m2e-wtp only supports a single web resource folder mapped to the <warSourceDirectory> attribute of maven-war-plugin. If multiple resource folders must be supported (as <webResources> in maven-war-plugin), an enhancement request should be opened in bugzilla

Convert project dependencies to Maven dependencies

The m2e conversion mechanism needs to be able to convert project dependencies into maven dependencies. Currently, a JBoss Tools experiment (EPL code) hacks into the conversion participant mechanism to provide a wizard allowing such conversion. The current implementation uses several strategies to identify jars (more or less bound to JBoss Tools). In the hypothesis where Red Hat contributes that feature back to m2e, some changes would be required :

• Ideally, the dependency conversion step would require its own page in m2e's conversion wizard.
• m2e would provide a couple default identification strategies (look inside the jar for maven metadata, do a SHA1 checksum search on the nexus index)
• other identification strategies could be contributed via extension points by 3rd party adopters.
• when dealing with WTP projects, how should target runtime containers be handled???

BZ link required

Add refactoring capabilities

User converting to Maven expect their projects to be transformed to follow the maven folder structure (among other things). We'd need to gather potential refactorings and have them displayed in a wizard page, so that the user could select what happens during the conversion.

• This would require another page in m2e's conversion wizard.
• refactorings should happen after selecting the project GAV and packaging and before the actual conversion (where the maven model is constructed by conversion participants)

See https://bugs.eclipse.org/bugs/show_bug.cgi?id=387458

Conversion participant ordering

Some conversion participants requires to be executed after other participants (ex. a buildhelper conversion participant adding extra sources would be executed after the java conversion participant).

• extensions point would declare a conversion participant needs to be invoke *after* ( a list of participant id). We basically need to implement some direct acyclic graph resolution to support this scenario.
• the ordered list of participants could be displayed in an advanced page, wher a user could select which participants, would be applied, in the order of his choice.

BZ links required

Other ideas

• Prevent any custom pom.xml conversion : https://bugs.eclipse.org/bugs/show_bug.cgi?id=388981. Add a Conversion Vetoer API? Or requirement could simply be met by manual selection mentioned in previous topic.