Maven 2.x Eclipse Plugin

missing artifact references with pde mode enabled

Details

  • Type: Bug Bug
  • Status: Open Open
  • Priority: Critical Critical
  • Resolution: Unresolved
  • Affects Version/s: 2.0, 2.1, 2.2, 2.3, 2.4, 2.5, 2.5.1
  • Fix Version/s: None
  • Labels:
    None
  • Environment:
    Maven version: 2.0.9
    Java version: 1.5.0_11
    OS name: "linux" version: "2.6.15-51-686" arch: "i386" Family: "unix"
  • Number of attachments :
    1

Description

Some artifacts are not referenced after executing mvn eclipse:eclipse and having pde mode enabled. The strange thing is, that this does only happen for particluar versions of an artifact.
Two artifacts that I found with this problem are jetty (org.mortbay.jetty) and slf4j-log4j12 (org.slf4j-log4j12). Jetty versions beyond 6.1.5 work with pde enabled, higher versions do not. Same for slf4j-log4j12 versions =< 1.1.0.

Attached is an example project demonstrating the problem. Turn pde mode on/off in the pom and execute mvn eclipse:eclipse.

Activity

Hide
Benjamin Voigt added a comment -

Mistake: I meant to say [...] jetty versions below 6.1.5 [...].

Show
Benjamin Voigt added a comment - Mistake: I meant to say [...] jetty versions below 6.1.5 [...].
Hide
Benjamin Voigt added a comment -

No solution or even similar issues for somebody ?
Meanwhile, the issue extends to the wicket library (org.apache.wicket:wicket) which, in version 1.3.x is included in the eclipse classpath while version 1.4-m2 is not.

Show
Benjamin Voigt added a comment - No solution or even similar issues for somebody ? Meanwhile, the issue extends to the wicket library (org.apache.wicket:wicket) which, in version 1.3.x is included in the eclipse classpath while version 1.4-m2 is not.
Hide
Benjamin Voigt added a comment -

Ok, after some investigation I found that this problem seems to be caused by two factors:
1. my project has pde enabled
2. the specific dependencies not working are osgi bundles.
This seems to be a bad combination as we have the following in the EclipseClasspathWriter Class:
...
if ( config.isPde() && ( dep.isProvided() || dep.isOsgiBundle() ) )
{
return;
...(line 415)
Thus, not adding for example, jetty 6.1.10 (or any of the above mentioned dependencies) to the classpath file.
Now my problem is that I neither understand why this is nor what I can do to add these dependencies to my project.

I am thankful for any suggestions

Show
Benjamin Voigt added a comment - Ok, after some investigation I found that this problem seems to be caused by two factors: 1. my project has pde enabled 2. the specific dependencies not working are osgi bundles. This seems to be a bad combination as we have the following in the EclipseClasspathWriter Class: ... if ( config.isPde() && ( dep.isProvided() || dep.isOsgiBundle() ) ) { return; ...(line 415) Thus, not adding for example, jetty 6.1.10 (or any of the above mentioned dependencies) to the classpath file. Now my problem is that I neither understand why this is nor what I can do to add these dependencies to my project. I am thankful for any suggestions
Hide
Gopalakrishnan U added a comment -

I am also hit by this problem. As Benjamin pointed out I also think the problem is on line 415. It should have been

if ( config.isPde() && dep.isProvided() && dep.isOsgiBundle() )

i.e, don't add the dependency to the classpath if the dependency is provided AND it is a bundle AND the project is a PDE project.
It needs to be added to the class path if the dependency was not provided or it is not a OSGi bundle. Here is the patch

Index: src/main/java/org/apache/maven/plugin/eclipse/writers/EclipseClasspathWriter.java
===================================================================
— src/main/java/org/apache/maven/plugin/eclipse/writers/EclipseClasspathWriter.java (revision 674713)
+++ src/main/java/org/apache/maven/plugin/eclipse/writers/EclipseClasspathWriter.java (working copy)
@@ -412,7 +412,7 @@

// if the dependency is not provided and the plugin runs in "pde mode", the dependency is
// added to the Bundle-Classpath:

  • if ( config.isPde() && ( dep.isProvided() || dep.isOsgiBundle() ) )
    + if ( config.isPde() && dep.isProvided() && dep.isOsgiBundle() ) { return; }

Gopal

Show
Gopalakrishnan U added a comment - I am also hit by this problem. As Benjamin pointed out I also think the problem is on line 415. It should have been if ( config.isPde() && dep.isProvided() && dep.isOsgiBundle() ) i.e, don't add the dependency to the classpath if the dependency is provided AND it is a bundle AND the project is a PDE project. It needs to be added to the class path if the dependency was not provided or it is not a OSGi bundle. Here is the patch Index: src/main/java/org/apache/maven/plugin/eclipse/writers/EclipseClasspathWriter.java =================================================================== — src/main/java/org/apache/maven/plugin/eclipse/writers/EclipseClasspathWriter.java (revision 674713) +++ src/main/java/org/apache/maven/plugin/eclipse/writers/EclipseClasspathWriter.java (working copy) @@ -412,7 +412,7 @@ // if the dependency is not provided and the plugin runs in "pde mode", the dependency is // added to the Bundle-Classpath:
  • if ( config.isPde() && ( dep.isProvided() || dep.isOsgiBundle() ) ) + if ( config.isPde() && dep.isProvided() && dep.isOsgiBundle() ) { return; }
Gopal
Hide
Gopalakrishnan U added a comment -

Oops! Just figured out that the patch doesn't work. needs more work.

Show
Gopalakrishnan U added a comment - Oops! Just figured out that the patch doesn't work. needs more work.
Hide
Benjamin Voigt added a comment - - edited

Any progress on this ? I would try to solve this myself but a "mvn install" on the maven-eclipse-plugin sources keeps stuck at the unit/integration tests with nearly 100 % cpu being used.

Show
Benjamin Voigt added a comment - - edited Any progress on this ? I would try to solve this myself but a "mvn install" on the maven-eclipse-plugin sources keeps stuck at the unit/integration tests with nearly 100 % cpu being used.
Hide
Arnaud Heritier added a comment -

The build can take 10 minutes or minutes depending of the hardware.
You can try to patch the code and launch the build bypassing tests to quickly the result on a project.

Show
Arnaud Heritier added a comment - The build can take 10 minutes or minutes depending of the hardware. You can try to patch the code and launch the build bypassing tests to quickly the result on a project.
Hide
Benjamin Voigt added a comment -

If it only were 10 minutes. After 40 minutes I killed the process because my system became totally unresponsive. Seems that the temporary files cause the trouble. Maybe it's an os specific problem, I'll look for that.

Show
Benjamin Voigt added a comment - If it only were 10 minutes. After 40 minutes I killed the process because my system became totally unresponsive. Seems that the temporary files cause the trouble. Maybe it's an os specific problem, I'll look for that.
Hide
Arnaud Heritier added a comment -

yes, 40 minutes is too long. You can have a look at surefire reports which store integration tests results to see if something is wrong with your plateform.

Show
Arnaud Heritier added a comment - yes, 40 minutes is too long. You can have a look at surefire reports which store integration tests results to see if something is wrong with your plateform.
Hide
Jacob Northey added a comment -

Is there a resolution for this? It would be nice to not have to download the source and maintain it internally.

Does anybody require the current implementation? i.e. is anybody using OSGi bundle dependencies that aren't marked as provided? It seems like most people use provided scope.

Show
Jacob Northey added a comment - Is there a resolution for this? It would be nice to not have to download the source and maintain it internally. Does anybody require the current implementation? i.e. is anybody using OSGi bundle dependencies that aren't marked as provided? It seems like most people use provided scope.
Hide
Edd Steel added a comment -

We are using commons-math as a compile scope dependency, which has been an OSGi bundle since 1.2 (https://issues.apache.org/jira/browse/MATH-180).

Show
Edd Steel added a comment - We are using commons-math as a compile scope dependency, which has been an OSGi bundle since 1.2 (https://issues.apache.org/jira/browse/MATH-180).
Hide
Benjamin Voigt added a comment -

@Edd Steel: Do you have pde mode enabled in the project where you use the commons-math bundle ?

Show
Benjamin Voigt added a comment - @Edd Steel: Do you have pde mode enabled in the project where you use the commons-math bundle ?
Hide
Simon Nickerson added a comment -

I am working on the same project as Edd Steel (above) - we have pde mode enabled in the project which depends on commons-math. We have got round it by downgrading to 1.1. There appears to be a similar issue with commons-io.

Show
Simon Nickerson added a comment - I am working on the same project as Edd Steel (above) - we have pde mode enabled in the project which depends on commons-math. We have got round it by downgrading to 1.1. There appears to be a similar issue with commons-io.
Hide
luke w patterson added a comment -

I see the same problem. When <pde> is enabled, some bundle dependencies are missing.

Show
luke w patterson added a comment - I see the same problem. When <pde> is enabled, some bundle dependencies are missing.
Hide
Eugene Voytitsky added a comment -

Maybe plugin's author had reasons for implementing such a skipping
but nowadays the more and more maven artifacts became osgi-fied,
so skipping osgi-bundled artifact from being included in MANIFEST classpath (and skipping it beign linked to project as linkedResource)
looks as unpractical.

Currently there are at least 2 places in src where fixes should be applied:
already mentioned EclipseClasspathWriter.java and also EclipseProjectWriter.java around the code:
if ( dep.isAddedToClasspath() && !dep.isProvided() && !dep.isReferencedProject()
&& !dep.isTestDependency() && !dep.isOsgiBundle() )
{

Actually it would be great to have ability to specify whether include osgi bundles or not in plugin configuration options.
Thanks.

Show
Eugene Voytitsky added a comment - Maybe plugin's author had reasons for implementing such a skipping but nowadays the more and more maven artifacts became osgi-fied, so skipping osgi-bundled artifact from being included in MANIFEST classpath (and skipping it beign linked to project as linkedResource) looks as unpractical. Currently there are at least 2 places in src where fixes should be applied: already mentioned EclipseClasspathWriter.java and also EclipseProjectWriter.java around the code: if ( dep.isAddedToClasspath() && !dep.isProvided() && !dep.isReferencedProject() && !dep.isTestDependency() && !dep.isOsgiBundle() ) { Actually it would be great to have ability to specify whether include osgi bundles or not in plugin configuration options. Thanks.

People

Vote (14)
Watch (12)

Dates

  • Created:
    Updated: