maven-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jacob Robertson (JIRA)" <j...@codehaus.org>
Subject [jira] Commented: (MNGECLIPSE-106) Dependency Resolver and PDE conflicts
Date Tue, 16 May 2006 12:55:41 GMT
    [ 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


Mime
View raw message