Hi Stuart,

Thanks for your reply - I think this explains the problem.

If I understand correctly, the workaround you are proposing is that I unpack
the contents of the "a" jar into "a/target/classes" during the package phase
(using antrun or dependency-plugin unless there is another approach)? 
Alternatively, I suppose I could use antrun to copy the classes for "a" into
"a/target/classes" before packaging and  thereby use the default
"classesDirectory" for the jar plugin...same difference I think.

thanks,

Shea.

Stuart McCulloch-3 wrote:
> 
> On 06/03/2008, shea <[EMAIL PROTECTED]> wrote:
>>
>>
>> Hello,
>>
>> I have a multi-module build that is essentially:
>>
>> jars---a
>>          b
>>          c
>>
>> Where jars is a directory that contains a parent/multimodule pom.xml that
>> builds a pom-type artifact called "jars-parent". a, b, and c are each
>> sub-directories within the jars directory with their own poms.  a, b, and
>> c,
>> all have jars-parent as their parent.  They are referenced as modules in
>> jars-parent's pom.xml in the same order.
>>
>> The problem arises in a situation when "c" depends on "a" for example. 
>> If
>> I
>> build each of the submodules independently in the the order "a, b, c",
>> everything is fine.  however, when I do a "mvn install" from the jars
>> directory, "a" and "b" build fine, but compilation of "c" fails - not an
>> artifact resolution problem, but a compilation problem. This is in spite
>> of
>> the fact that "a" was built and installed to my local repo just fine.
>>
>> The only unusual thing I am doing is that "a" doesn't actually compile
>> anything - it just packages some existing class files using the jar
>> plugin.
>> (this is part of an ant conversion - don't get me started :,( )
>>
>> I have had other multi-module build work just fine, but I am hoping
>> somebody
>> can point out some potential gotchas that I am overlooking.
> 
> 
> This is due to a "feature" in the MavenProject class when running
> a reactor (ie. multi-module) compilation.  Normally when it builds
> the compilation classpath, it will use the location of the artifact in
> the local maven repository - and your setup will work fine.
> 
> However, with a reactor build you may be running "mvn compile"
> and not installing artifacts, so there's code inside MavenProject
> (addArtifactPath) that changes the compilation classpath to use:
> 
>    <artifact-module>/<build.outputDirectory>
> 
> instead of the location of the local repository - I think the reason
> for this is because you want to compile against the latest code
> and the jar in the repository may be stale if you're not doing an
> "install" at the same time as "compile"
> 
> unfortunately this doesn't work so well with projects that create
> artifacts without populating "target/classes" because then the
> compilation classpath will contain the empty directory, not the
> actual artifact with the classes :(
> 
> the safest workaround I've found is to unpack the contents of
> the jar to the build.outputDirectory during the packaging phase
> so the classes are found where MavenProject expects them
> 
> a potential fix for the MavenProject class might be to add the
> outputDirectory before the artifact's location in the local repo,
> rather than replacing it in the compilation classpath - however
> this is a rather central part of Maven so modifying its behavior
> should be done very carefully...
> 
> HTH
> 
> Thanks,
>>
>> Shea.
>>
>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/artifacts-build-fine-on-their-own-but-fail-in-multi-module-build-tp15863045s177p15863045.html
>> Sent from the Maven - Users mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
> 
> 
> -- 
> Cheers, Stuart
> 
> 

-- 
View this message in context: 
http://www.nabble.com/artifacts-build-fine-on-their-own-but-fail-in-multi-module-build-tp15863045s177p15901229.html
Sent from the Maven - Users mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to