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
Assigned to: 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
