Bugzilla – Full Text Bug Listing
| Summary: | [patch] Provide a way to allow customization of the maven model when converting to a Maven project | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | z_Archived | Reporter: | Fred Bricon <fbricon> | ||||||||
| Component: | m2e | Assignee: | Igor Fedorenko <igor> | ||||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||||
| Severity: | enhancement | ||||||||||
| Priority: | P3 | CC: | adietish, igor, jjensen, taciano.tres | ||||||||
| Version: | unspecified | ||||||||||
| Target Milestone: | --- | ||||||||||
| Hardware: | All | ||||||||||
| OS: | All | ||||||||||
| Whiteboard: | |||||||||||
| Attachments: |
|
||||||||||
|
Description
Fred Bricon
After thinking and discussing about that with Igor, here are a few more ideas :
Eclipse plugins would contribute to a new extension point and implement a new interface, let's call it IProjectConversionParticipant, having 2 methods :
- boolean accept(IProject project)
- void convert(IProject project, Model mavenModel)
On the Configure > Convert to Maven project action/command, after the user has chosen the GAV coordinates and package for the project in the wizard, instead of serializing the maven model directly, all conversion participants are retrieved (ordered with a priority would be a good idea) and called in that fashion :
for (IProjectConversionParticipant converter : getProjectConversionParticipants() {
if (converter.accept(project) {
converter.convert(project, model);
}
}
That way :
* m2e-jdt (highest priority) adds the maven-compiler-plugin to the model if the javaNature is present on the project, setting the source/target values based on the existing eclipse settings
* m2e-wtp adds the maven-war-plugin, maven-ear-plugin, maven-ejb-plugin and so on, based on existing installed project facets
* m2e-tycho would add the tycho plugin or bundle plugin configuration (TBD) if the PluginNature is present
* m2e-android would add the maven-android-plugin configuration for android projects.
and so on and so forth ...
Note that approach has at least 2 drawbacks :
- that would trigger an early eclipse plugin activation for all plugins contributing converters
- I don't see how this can integrate with the m2e extension discovery mechanism.
What component is going to decide if a PDE Bundle project should be converted to a Tycho or a maven-bundle-plugin project? For argument sake, lets assume that m2e/tycho and m2e/maven-bundle-plugin are two separate m2e extensions. Likewise, what component is going to decide if a project with both PDE Bundle and WTP Dynamic Webapp natures/facets should be converted to a war, a tycho or a maven-bundle-plugin Maven project? The packaging is already set by the user in the Wizard page. I believe the converters can decide what to do based on that information. Before displaying the wizard, we could also pre-set the package based on a IProjectConversionParticipant.guessPackage(IProject) method. If one and only one converter returns a non-null value, then it'd be set as the default package. So if we had the wtp and tycho converters propose war and eclipse-plugin respectively, then the package type would be empty in the wizard, forcing the user to choose a value. Created attachment 209003 [details]
Proposed patch to implement the feature
Created attachment 209004 [details]
Test cases for project conversion
@Fred, as required by [1] can you confirm that: 1. Contains No Cryptography 2. Is Developed from Scratch (without incorporating content from elsewhere) 3. Is 100% Project License Code and (a) you wrote 100% of the code; (b) that you have the right to contribute the code to Eclipse; (c) the file header contains the appropriate License header [1] http://eclipse.org/legal/EclipseLegalProcessPoster.pdf I confirm that the contribution : 1. Contains no cryptography. 2. Is developed from scratch. Jboss Tools Maven integration (EPL v1.0 license) contains code that provide a similar feature, but nothing was copied or reused from it. 3. Is 100% Eclipse Public License v1.0 Code. and (a) I wrote 100% of the code; (b) Red Hat has a company wide agreement that authorizes me to contribute the code to Eclipse; (c) Modified files retain their existing header. All new files contain the following header : /******************************************************************************* * Copyright (c) 2012 Red Hat, Inc. * All rights reserved. This program and the accompanying materials * are made available under the terms of the Eclipse Public License v1.0 * which accompanies this distribution, and is available at * http://www.eclipse.org/legal/epl-v10.html * * Contributors: * Red Hat, Inc. - initial API and implementation *******************************************************************************/ opened CQ 5947 @Fred looks like attached test patch is missing all .project/.classpath/.settings files. Can you please double-check and re-attach proper patch? Created attachment 210236 [details]
Test cases for project conversion including eclipse settings
Sorry I didn't realize the eclipse files were ignored by git.
Here's a new patch for the test cases.
Applied the patches, thank you. *** Bug 346843 has been marked as a duplicate of this bug. *** |