[ http://jira.codehaus.org/browse/MNGECLIPSE-106?page=comments#action_65450 ]
Jacob Robertson commented on MNGECLIPSE-106: -------------------------------------------- +1 from my company - this is a critical issue for us, and will be a deal breaker for some of our teams, because we cannot develop PDE projects while using the m2eclipse tool as it stands right now. > Dependency Resolver and PDE conflicts > ------------------------------------- > > Key: MNGECLIPSE-106 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-106 > Project: Maven 2.x Extension for Eclipse > Type: Improvement > Components: Dependency Resolver > Environment: Eclipse PDE > Reporter: Dimitry Voytenko > Assignee: Eugene Kuleshov > Attachments: sample-plugins.zip > > > All tests have been done using the solution provided in the > http://jira.codehaus.org/browse/MNGECLIPSE-59. This solution works very well, > but there're specifics when using it in the PDE (Plugin Development) > environment. > Attached are sample plugins that demonstrate the issue (tested under Eclipse > 3.1.2). Unpack sample-plugins.zip and import projects in the workspace. Patch > from MNGECLIPSE-59 should be applied. Rebuild both projects. Build of > "com.example.plugins.main" should fail with an error: > "Build path contains duplicate entry: 'com.example.plugins.component' for > project com.example.plugins.main" > The problem occures b/c of conflict b/w PDE classpath container and Maven2 > classpath container. They both contain "com.example.plugins.component" > project. > PDE's classpath container is defined in the org.eclipse.pde.core plugin as an > org.eclipse.pde.core.requiredPlugins extension. It uses META-INF/MANIFEST.MF > file as a source. MANIFEST.MF is basically an OSGI manifest that lists all > dependent bundles in the form: > Require-Bundle: org.eclipse.core.runtime, ... > with optionally specified version and transiting information. > Both manifest and PDE container are very essential for the PDE work. It's not > clear if they can be properly extended to avoid conflicts. > If such a way can be found, it is important to keep in mind the similarities > and differences b/w Maven and PDE dependency management: > a) PDE dependencies have flags "optional" and "re-exported". By default > dependencies are required and non-transient. The "optional" property can be > modeled via Maven'2 optional dependency. The re-exported property basically > makes the dependency transient. I'm not sure if all of these states can be > modelled via Maven's scope. > b) Version management is different. PDE allows to specify dependency on the > latest found version of a plugin (if version parameters is specified then it > should be greater or equal). In Eclipse 3.2 it's actually possible to specify > both borders, i.e. version no earlier than 2.0.0 and no later than 3.0.0. > c) MANIFEST.MF is a deployable file. It's used at runtime to build the > classloader graph. > If it's not possible to extend PDE to source it from the Maven's > configuration a temporary solution could be to exclude a dependent project > from the Maven container if it can be found elsewhere in the classpath. The > possible issue here: if it's possible to get the access from Maven container > to the content of the other containers. > Cooperation with Eclipse team would probably help here as this would also > benefit them in the long run. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
