Maven 2 & 3

Multiproject dependencies not accurate for project.compileClasspathElements when run from root project

Details

  • Complexity:
    Intermediate
  • Number of attachments :
    0

Description

In a plugin I wrote (jspc), needs the dependency jars. It asks for this with the request for the project.compileClasspathElements. In a multiproject environment, when each project is built individually, it seems correct. Example (when run with -X ina subproject dir) showing classpath:

/Users/mbp/.m2/repository/javax/servlet/jsp-api/2.0/jsp-api-2.0.jar
/Users/mbp/.m2/repository/taglibs/standard/1.1.2/standard-1.1.2.jar
/Users/mbp/.m2/repository/javax/servlet/servlet-api/2.4/servlet-api-2.4.jar
/Users/mbp/.m2/repository/tldtestapp/testexttld/1/testexttld-1.jar <-----------------NOTICE HERE - THIS IS AN ARTIFACT FROM ANOTHER SUBPROJECT
/Users/mbp/.m2/repository/javax/servlet/jstl/1.1.2/jstl-1.1.2.jar]

When it is run from the Top level/Root project...here is the output:

Users/mbp/.m2/repository/javax/servlet/jsp-api/2.0/jsp-api-2.0.jar
/Users/mbp/.m2/repository/javax/servlet/servlet-api/2.4/servlet-api-2.4.jar
/Users/mbp/.m2/repository/taglibs/standard/1.1.2/standard-1.1.2.jar
/Users/mbp/Desktop/jsp-example/TestTldProject/target/classes <----------------NOTICE - THE JAR IS NOT BEING ASKED FOR, BUT A CLASSES DIR INSTEAD
/Users/mbp/.m2/repository/javax/servlet/jstl/1.1.2/jstl-1.1.2.jar]

The second project has a dependency on the testexttld-1.jar because it contains tag libs which must be wrapped in a jar. When run from a top level, it uses the other project's classes directory instead of the JAR artifact. WIth JSPC and taglibs, this makes it so it cannot work. If I have a dependency on a jar, that jar should be the dependency as expected and not a classes directory. For full explanation and example see here:

http://jira.codehaus.org/browse/MJSPC-4

Issue Links

is duplicated by

Bug - A problem which impairs or prevents the functions of the product. MNG-2151 classpath used to build a module affects compile classpath for building another module

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Bug - A problem which impairs or prevents the functions of the product. MNG-3420 In a reactor, attached artifacts with classifier should be used when generating classpath, instead of the whole output directory of the related project

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Bug - A problem which impairs or prevents the functions of the product. MNG-4032 Test jar dependency not available for for main classes in multi module builds

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Improvement - An improvement or enhancement to an existing feature or task. MNG-4608 Cross module dependencies for multi-module projects

  • Blocker - Blocks development and/or testing work, production could not run
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.
is related to

Bug - A problem which impairs or prevents the functions of the product. MJSPC-4 JSPs Cannot Be Compiled if They Depend on Tag Files

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.
relates to

Bug - A problem which impairs or prevents the functions of the product. MNG-2045 Maven can't compile against sibling test-jar dependency in multiproject (Test Attached)

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Bug - A problem which impairs or prevents the functions of the product. MNG-4248 CLONE -Maven can't compile against sibling test-jar dependency in multiproject (Test Attached)

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Bug - A problem which impairs or prevents the functions of the product. MSHADE-42 Reactor builds do not use shaded jar

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Stuart McCulloch added a comment -

This is also affecting Spring-OSGi...

The current Spring-OSGi build includes sub-projects to wrap existing Spring modules as OSGi bundles.
During this wrapping process, the bundle is created and installed without unpacking the jar, so the build
output directory (target/classes) is empty.

Later on in the build, other sub-projects have dependencies to the OSGified modules - but because the
dependent sub-projects are in the project references, the MavenProject class only adds the build output
directories to the compilation classpath (instead of the artifacts in the local repo).

This causes the build to fail, because the target/classes directories are empty - if the MavenProject class
also added the artifact jar as well as the output directory to the classpath then the build would pass.

Currently we are working around this problem by using the invoker plugin to separate the build cycles.

Show
Stuart McCulloch added a comment - This is also affecting Spring-OSGi... The current Spring-OSGi build includes sub-projects to wrap existing Spring modules as OSGi bundles. During this wrapping process, the bundle is created and installed without unpacking the jar, so the build output directory (target/classes) is empty. Later on in the build, other sub-projects have dependencies to the OSGified modules - but because the dependent sub-projects are in the project references, the MavenProject class only adds the build output directories to the compilation classpath (instead of the artifacts in the local repo). This causes the build to fail, because the target/classes directories are empty - if the MavenProject class also added the artifact jar as well as the output directory to the classpath then the build would pass. Currently we are working around this problem by using the invoker plugin to separate the build cycles.
Hide
Permalink
Grégory Joseph added a comment -

any news on this ?

Show
Grégory Joseph added a comment - any news on this ?
Hide
Permalink
Sana Ghariani added a comment -

I have the same problem.
When this will be fixed?

Show
Sana Ghariani added a comment - I have the same problem. When this will be fixed?
Hide
Permalink
Kaizer Sogiawala added a comment -

I think I have a workaround for this one.

I created a Grouping POM (BOM-POM) and listed all the dependencies that are getting fizzled out downsteam in the grouping POM. I then replaced the individual dependencies from the downstream projects with one dependency on the grouping POM. That seemed to marshal all the jars properly in the reactor build.

So effectively aggregate all the dependencies in the grouping POM and consume that POM downstream. Remember to use the <packaging>pom</packaging> and <type>pom</type> for the grouper.

Show
Kaizer Sogiawala added a comment - I think I have a workaround for this one. I created a Grouping POM (BOM-POM) and listed all the dependencies that are getting fizzled out downsteam in the grouping POM. I then replaced the individual dependencies from the downstream projects with one dependency on the grouping POM. That seemed to marshal all the jars properly in the reactor build. So effectively aggregate all the dependencies in the grouping POM and consume that POM downstream. Remember to use the <packaging>pom</packaging> and <type>pom</type> for the grouper.
Hide
Permalink
Benjamin Bentmann added a comment -

Merged to 3.x in r747588.

Show
Benjamin Bentmann added a comment - Merged to 3.x in r747588 .
Hide
Permalink
Gabriel Guerrero added a comment -

I have a problem with this fix, I have several projects, and I use and the ant plugin to run my app in debug mode, what i liked is that because the classes directories was included in the classpath I was able to run eclipse in debug mode for multi projects so I could change a classes in any of the projects and just run compile , know this doesnt work could it you guys add a flag to make it work the old way?

Show
Gabriel Guerrero added a comment - I have a problem with this fix, I have several projects, and I use and the ant plugin to run my app in debug mode, what i liked is that because the classes directories was included in the classpath I was able to run eclipse in debug mode for multi projects so I could change a classes in any of the projects and just run compile , know this doesnt work could it you guys add a flag to make it work the old way?

People

  • Assignee:
    John Casey
    Reporter:
    Jeff Genender
Vote (15)
Watch (10)

Dates

  • Created:
    Updated:
    Resolved: