You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Dimitry Voytenko (JIRA)" <ji...@codehaus.org> on 2006/04/27 04:19:19 UTC
[jira] Created: (MNGECLIPSE-106) Dependency Resolver and PDE
conflicts
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
[jira] Commented: (MNGECLIPSE-106) Dependency Resolver and PDE
conflicts
Posted by "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
[jira] Updated: (MNGECLIPSE-106) Dependency Resolver and PDE
conflicts
Posted by "Eugene Kuleshov (JIRA)" <ji...@codehaus.org>.
[ 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
[jira] Commented: (MNGECLIPSE-106) Dependency Resolver and PDE
conflicts
Posted by "Scott Cytacki (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNGECLIPSE-106?page=comments#action_67837 ]
Scott Cytacki commented on MNGECLIPSE-106:
------------------------------------------
I've found a way to have a maven project double as a eclipse plugin. I don't know if this solves your particular problem but it is mostly working for me. My main problem is that I have two types of dependencies:
1. Those that are available as both maven artifacts and plugins.
2. Those that are only available as maven artifacts.
If a project has dependencies of type 1. Then it is easy, simply choose between the maven classpath container and the plugin classpath container. Remove one of them. Even if you remove the plugin classpath container, the plugin project can still be used by other plugin projects and it can still be used in a testing eclipse application.
If a project has dependencies of type 2, then make a second plugin project that contains those maven dependencies. So lets say the project you are working with is called: MyPlugin. It has maven deps on jug and xstream. If you add jug and xtream to the MyPlugin plugin classpath you will get conflicts. So instead make a new plugin project called MyPluginDeps, and add jug and xstream to this project. Now change the MyPlugin manifest.mf so it depends on MyPluginDeps.
Now the MyPlugin project will build with either the maven classpath container or the plugin classpath container.
This isn't the perfect solution:
1. the dependencies need to be updated in two places.
2. if the dependencies are not the same you might have different jars at runtime than at compile time.
The way I'm managing the dependencies right now is to use the maven assembly:assembly goal with the descriptorId set to "jar-with-dependencies" This creates a single jar that contains all dependencies combined into one jar. I then copy this jar into the MyPluginDeps project.
> 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