[jira] Commented: (MNGECLIPSE-106) Dependency Resolver and PDE conflicts

["Jacob Robertson (JIRA)" <ji...@codehaus.org>]

    [ 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