You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by shea <sh...@gmail.com> on 2008/03/06 00:28:08 UTC
artifacts build fine on their own but fail in multi-module build
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.
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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: artifacts build fine on their own but fail in multi-module build
Posted by Stuart McCulloch <st...@jayway.net>.
On 08/03/2008, shea <sh...@gmail.com> wrote:
>
>
> 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.
correct - btw, you can use "mvn -X install" to see the compilation classpath
used during a build - it also produces a lot of other debug, so best pipe it
to
a file and search thru it later for classpath entries
thanks,
>
> Shea.
>
>
> Stuart McCulloch-3 wrote:
> >
> > On 06/03/2008, shea <sh...@gmail.com> 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.xmlthat
> >> 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: users-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: users-help@maven.apache.org
> >>
> >>
> >
> >
> > --
> > 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: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
Cheers, Stuart
Re: artifacts build fine on their own but fail in multi-module
build
Posted by shea <sh...@gmail.com>.
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 <sh...@gmail.com> 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: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
>
> --
> 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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: artifacts build fine on their own but fail in multi-module build
Posted by Stuart McCulloch <st...@jayway.net>.
On 06/03/2008, shea <sh...@gmail.com> 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: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
Cheers, Stuart