[ http://jira.codehaus.org/browse/MNGECLIPSE-106?page=all ]
Eugene Kuleshov updated MNGECLIPSE-106:
---------------------------------------
Assignee: (was: Eugene Kuleshov)
> Dependency Resolver and PDE conflicts
> -------------------------------------
>
> Key: MNGECLIPSE-106
> URL: http://jira.codehaus.org/browse/MNGECLIPSE-106
> Project: Maven 2.x Extension for Eclipse
> Issue Type: Improvement
> Components: Dependency Resolver
> Environment: Eclipse PDE
> Reporter: Dimitry Voytenko
> 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
