Maven 2 & 3
  1. Maven 2 & 3
  2. MNG-2720

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

          Activity

          Hide
          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
          Grégory Joseph added a comment -

          any news on this ?

          Show
          Grégory Joseph added a comment - any news on this ?
          Hide
          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
          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
          Benjamin Bentmann added a comment -

          Merged to 3.x in r747588.

          Show
          Benjamin Bentmann added a comment - Merged to 3.x in r747588 .
          Hide
          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
            • Votes:
              15 Vote for this issue
              Watchers:
              10 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: