[ 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
