You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Stuart McCulloch (JIRA)" <ji...@codehaus.org> on 2007/05/11 13:41:12 UTC

[jira] Commented: (MNG-2720) Multiproject dependencies not accurate for project.compileClasspathElements when run from root project

    [ http://jira.codehaus.org/browse/MNG-2720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_95654 ] 

Stuart McCulloch commented on MNG-2720:
---------------------------------------

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.

> Multiproject dependencies not accurate for project.compileClasspathElements when run from root project
> ------------------------------------------------------------------------------------------------------
>
>                 Key: MNG-2720
>                 URL: http://jira.codehaus.org/browse/MNG-2720
>             Project: Maven 2
>          Issue Type: Bug
>          Components: Plugins and Lifecycle
>    Affects Versions: 2.0.4
>            Reporter: Jeff Genender
>
> 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

-- 
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