Using the dependency resolution code in a mojo

[Nigel Magnay <ni...@gmail.com>]

Hi devs - I'm hoping for a pointer or two as to how easy this might be
to implement in practice - I think it shouldn't be too hard, but I'm
not really familiar with the possibly subtle interactions.

We build many WAR files in M2. We then merge these together at the
end, in order to create an 'uberwar' - this is done using the cargo
uberwar plugin, and from a dependency point of view, all it does is
that the output will contain all of the dependencies of the war
projects files in /lib.

This is good - but - there's a slightly annoying problem. If the
output is C.WAR, made from A.WAR and B.WAR.
A declares it uses X:jar:1.0, and gains a number of things from that
transitively.
B declares it uses X:jar:1.1, and gains some other things from that,
transitively.
C is the merged output, and so contains X:jar:1.0 AND X:jar:1.1 AND
any differences in transitive deps between X:jar:1.0 and X:jar:1.1.

If everything had been a JAR file, then maven does the clever
dependency analysis, and should end up with one or the other.

So - my question is - is it possible to use the maven core to get me
the 'correct' result? So instead of just keeping the contents of /lib
from A and B, re-calculating the 'correct' files to be there.

I have looked at the maven-dependency-plugin and
maven-dependency-tree, but I'm not sure I understand how to do
traversal from dependencies (or even if I'm looking at the correct
area of code to do this). I can see the ArtifactsPackagingTask in the
maven-war-plugin, but I'm not sure how I'd get to a MavenProject from
an Artifact if I needed to find dependencies recursively.. And then
apply the 'calculate effective dependencies' process ?

Has anyone got any hints (or perhaps a different plugin that does
something similar) ?

TIA,
Nigel

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Using the dependency resolution code in a mojo

[Nigel Magnay <ni...@gmail.com>]

Thanks for that.
I ended up by patching the cargo uberwar behaviour and adding
a <resolveDependencies>true</resolveDependencies>
option, which makes the lib directory contain the 'correct, calculated'
dependencies.

I resorted to a hideous hack to do it (generating "shadow" pom files in the
repository with "war" types converted to be "pom" types), but it seems to
work, and someone else with more maven-internals-fu can fix it later if
needed.


On Nov 8, 2007 3:21 PM, Mark Struberg <st...@yahoo.de> wrote:

> look at
> http://jira.codehaus.org/browse/MWAR-73
>
> There you'll find the basic info how to handle archivedClasses as attached
> artifact and also a
> patch from Michael which generally fixes the war-overlaying.
>
> hope this is what u r looking 4
>
> LieGrü,
> strub
>
> --- Nigel Magnay <ni...@gmail.com> schrieb:
>
> > Ah - interesting - I hadn't considered the archiveClasses part. Does
> > it then get it's own pom file with <type>jar</type> ? Is it a
> > complicated patch to the WAR plugin?
> >
> > Sounds like you're trying to do exactly the same thing as me, where
> > the path to a 'final' war may have WAR files that depend on other
> > 'WAR' files.
> >
> > I was hoping it could be done in code though (well, I'm convinced it
> > can be, I'm just not convinced that I understand enough of the
> > internals to do it. The POM data and the repository seems to have all
> > the information needed, I just need to figure out how to hook it all
> > together..
> >
> >
> > On Nov 8, 2007 2:34 PM, Mark Struberg <st...@yahoo.de> wrote:
> > > Ouch ;)
> > >
> > > The problem with the uberwar is, that (for what i know - i looked at
> the sources over 2 years
> > ago,
> > > so this might have changed) it has no information anymore about what
> kind of libraries are in
> > the
> > > WEB-INF/lib directory (and if those libs are maintained via maven or
> not). So it imho only
> > copies
> > > the jars on a file basis to a temporary destination directory one
> after the other. If you used
> > > different versions of one and the same artifact in your dependencies,
> you will end up having
> > > multiple different jars in the final WEB-INF/lib.
> > >
> > > I had similar problems and took a somehow different way to get it
> done:
> > >
> > > 1.) I don't use the cargo:uberwar but the maven-war-plugin. I patched
> the maven-war-plugin so
> > that
> > > if you activate 'archiveClasses' the webclasses.jar will not only be
> packed into the war but
> > also
> > > marked as attachedArtifact. This way the webclasses.jar will also be
> stored in the repository
> > and
> > > thus may be used as dependency.
> > >
> > > 2.) I basically ignore ALL libs from the dependent wars (exclude
> WEB-INF/lib/*) and add
> > > dependencies to the dependend wars AND the appropriate webclasse.jarartifacts. (Setting the
> > > version number with properties is a good idea to not mix them up
> here.)
> > > This way i get all the dependencies resolved by maven (which does all
> the version conflict
> > > resolution for me, or at least I can overrule this by manually setting
> the dependency) and the
> > > compilation results from the dependent wars too in my final wars
> WEB-INF/lib folder.
> > >
> > > I hope my explanation makes sense to you. We use this mechanism with 3
> dependency layers and
> > up to
> > > ~10 wars (to e.g. build napsterMobile), so it's a bit complicated but
> definitely works ;)
> > >
> > > LieGrü,
> > > strub
> > >
> > > --- Nigel Magnay <ni...@gmail.com> schrieb:
> > >
> > >
> > > > Hi devs - I'm hoping for a pointer or two as to how easy this might
> be
> > > > to implement in practice - I think it shouldn't be too hard, but I'm
> > > > not really familiar with the possibly subtle interactions.
> > > >
> > > > We build many WAR files in M2. We then merge these together at the
> > > > end, in order to create an 'uberwar' - this is done using the cargo
> > > > uberwar plugin, and from a dependency point of view, all it does is
> > > > that the output will contain all of the dependencies of the war
> > > > projects files in /lib.
> > > >
> > > > This is good - but - there's a slightly annoying problem. If the
> > > > output is C.WAR, made from A.WAR and B.WAR.
> > > > A declares it uses X:jar:1.0, and gains a number of things from that
> > > > transitively.
> > > > B declares it uses X:jar:1.1, and gains some other things from that,
> > > > transitively.
> > > > C is the merged output, and so contains X:jar:1.0 AND X:jar:1.1 AND
> > > > any differences in transitive deps between X:jar:1.0 and X:jar:1.1.
> > > >
> > > > If everything had been a JAR file, then maven does the clever
> > > > dependency analysis, and should end up with one or the other.
> > > >
> > > > So - my question is - is it possible to use the maven core to get me
> > > > the 'correct' result? So instead of just keeping the contents of
> /lib
> > > > from A and B, re-calculating the 'correct' files to be there.
> > > >
> > > > I have looked at the maven-dependency-plugin and
> > > > maven-dependency-tree, but I'm not sure I understand how to do
> > > > traversal from dependencies (or even if I'm looking at the correct
> > > > area of code to do this). I can see the ArtifactsPackagingTask in
> the
> > > > maven-war-plugin, but I'm not sure how I'd get to a MavenProject
> from
> > > > an Artifact if I needed to find dependencies recursively.. And then
> > > > apply the 'calculate effective dependencies' process ?
> > > >
> > > > Has anyone got any hints (or perhaps a different plugin that does
> > > > something similar) ?
> > > >
> > > > TIA,
> > > > Nigel
> > > >
> > > >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > >
> > > >
> > >
> > >
> > >
> > >       Machen Sie Yahoo! zu Ihrer Startseite. Los geht's:
> > > http://de.yahoo.com/set
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
>
>
>      Jetzt Mails schnell in einem Vorschaufenster überfliegen. Dies und
> viel mehr bietet das neue Yahoo! Mail - www.yahoo.de/mail
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Re: Using the dependency resolution code in a mojo

[Mark Struberg <st...@yahoo.de>]

look at 
http://jira.codehaus.org/browse/MWAR-73

There you'll find the basic info how to handle archivedClasses as attached artifact and also a
patch from Michael which generally fixes the war-overlaying.

hope this is what u r looking 4

LieGrü,
strub

--- Nigel Magnay <ni...@gmail.com> schrieb:

> Ah - interesting - I hadn't considered the archiveClasses part. Does
> it then get it's own pom file with <type>jar</type> ? Is it a
> complicated patch to the WAR plugin?
> 
> Sounds like you're trying to do exactly the same thing as me, where
> the path to a 'final' war may have WAR files that depend on other
> 'WAR' files.
> 
> I was hoping it could be done in code though (well, I'm convinced it
> can be, I'm just not convinced that I understand enough of the
> internals to do it. The POM data and the repository seems to have all
> the information needed, I just need to figure out how to hook it all
> together..
> 
> 
> On Nov 8, 2007 2:34 PM, Mark Struberg <st...@yahoo.de> wrote:
> > Ouch ;)
> >
> > The problem with the uberwar is, that (for what i know - i looked at the sources over 2 years
> ago,
> > so this might have changed) it has no information anymore about what kind of libraries are in
> the
> > WEB-INF/lib directory (and if those libs are maintained via maven or not). So it imho only
> copies
> > the jars on a file basis to a temporary destination directory one after the other. If you used
> > different versions of one and the same artifact in your dependencies, you will end up having
> > multiple different jars in the final WEB-INF/lib.
> >
> > I had similar problems and took a somehow different way to get it done:
> >
> > 1.) I don't use the cargo:uberwar but the maven-war-plugin. I patched the maven-war-plugin so
> that
> > if you activate 'archiveClasses' the webclasses.jar will not only be packed into the war but
> also
> > marked as attachedArtifact. This way the webclasses.jar will also be stored in the repository
> and
> > thus may be used as dependency.
> >
> > 2.) I basically ignore ALL libs from the dependent wars (exclude WEB-INF/lib/*) and add
> > dependencies to the dependend wars AND the appropriate webclasse.jar artifacts. (Setting the
> > version number with properties is a good idea to not mix them up here.)
> > This way i get all the dependencies resolved by maven (which does all the version conflict
> > resolution for me, or at least I can overrule this by manually setting the dependency) and the
> > compilation results from the dependent wars too in my final wars WEB-INF/lib folder.
> >
> > I hope my explanation makes sense to you. We use this mechanism with 3 dependency layers and
> up to
> > ~10 wars (to e.g. build napsterMobile), so it's a bit complicated but definitely works ;)
> >
> > LieGrü,
> > strub
> >
> > --- Nigel Magnay <ni...@gmail.com> schrieb:
> >
> >
> > > Hi devs - I'm hoping for a pointer or two as to how easy this might be
> > > to implement in practice - I think it shouldn't be too hard, but I'm
> > > not really familiar with the possibly subtle interactions.
> > >
> > > We build many WAR files in M2. We then merge these together at the
> > > end, in order to create an 'uberwar' - this is done using the cargo
> > > uberwar plugin, and from a dependency point of view, all it does is
> > > that the output will contain all of the dependencies of the war
> > > projects files in /lib.
> > >
> > > This is good - but - there's a slightly annoying problem. If the
> > > output is C.WAR, made from A.WAR and B.WAR.
> > > A declares it uses X:jar:1.0, and gains a number of things from that
> > > transitively.
> > > B declares it uses X:jar:1.1, and gains some other things from that,
> > > transitively.
> > > C is the merged output, and so contains X:jar:1.0 AND X:jar:1.1 AND
> > > any differences in transitive deps between X:jar:1.0 and X:jar:1.1.
> > >
> > > If everything had been a JAR file, then maven does the clever
> > > dependency analysis, and should end up with one or the other.
> > >
> > > So - my question is - is it possible to use the maven core to get me
> > > the 'correct' result? So instead of just keeping the contents of /lib
> > > from A and B, re-calculating the 'correct' files to be there.
> > >
> > > I have looked at the maven-dependency-plugin and
> > > maven-dependency-tree, but I'm not sure I understand how to do
> > > traversal from dependencies (or even if I'm looking at the correct
> > > area of code to do this). I can see the ArtifactsPackagingTask in the
> > > maven-war-plugin, but I'm not sure how I'd get to a MavenProject from
> > > an Artifact if I needed to find dependencies recursively.. And then
> > > apply the 'calculate effective dependencies' process ?
> > >
> > > Has anyone got any hints (or perhaps a different plugin that does
> > > something similar) ?
> > >
> > > TIA,
> > > Nigel
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> >
> >
> >
> >       Machen Sie Yahoo! zu Ihrer Startseite. Los geht's:
> > http://de.yahoo.com/set
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 
> 



      Jetzt Mails schnell in einem Vorschaufenster überfliegen. Dies und viel mehr bietet das neue Yahoo! Mail - www.yahoo.de/mail

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Using the dependency resolution code in a mojo

[Nigel Magnay <ni...@gmail.com>]

Ah - interesting - I hadn't considered the archiveClasses part. Does
it then get it's own pom file with <type>jar</type> ? Is it a
complicated patch to the WAR plugin?

Sounds like you're trying to do exactly the same thing as me, where
the path to a 'final' war may have WAR files that depend on other
'WAR' files.

I was hoping it could be done in code though (well, I'm convinced it
can be, I'm just not convinced that I understand enough of the
internals to do it. The POM data and the repository seems to have all
the information needed, I just need to figure out how to hook it all
together..


On Nov 8, 2007 2:34 PM, Mark Struberg <st...@yahoo.de> wrote:
> Ouch ;)
>
> The problem with the uberwar is, that (for what i know - i looked at the sources over 2 years ago,
> so this might have changed) it has no information anymore about what kind of libraries are in the
> WEB-INF/lib directory (and if those libs are maintained via maven or not). So it imho only copies
> the jars on a file basis to a temporary destination directory one after the other. If you used
> different versions of one and the same artifact in your dependencies, you will end up having
> multiple different jars in the final WEB-INF/lib.
>
> I had similar problems and took a somehow different way to get it done:
>
> 1.) I don't use the cargo:uberwar but the maven-war-plugin. I patched the maven-war-plugin so that
> if you activate 'archiveClasses' the webclasses.jar will not only be packed into the war but also
> marked as attachedArtifact. This way the webclasses.jar will also be stored in the repository and
> thus may be used as dependency.
>
> 2.) I basically ignore ALL libs from the dependent wars (exclude WEB-INF/lib/*) and add
> dependencies to the dependend wars AND the appropriate webclasse.jar artifacts. (Setting the
> version number with properties is a good idea to not mix them up here.)
> This way i get all the dependencies resolved by maven (which does all the version conflict
> resolution for me, or at least I can overrule this by manually setting the dependency) and the
> compilation results from the dependent wars too in my final wars WEB-INF/lib folder.
>
> I hope my explanation makes sense to you. We use this mechanism with 3 dependency layers and up to
> ~10 wars (to e.g. build napsterMobile), so it's a bit complicated but definitely works ;)
>
> LieGrü,
> strub
>
> --- Nigel Magnay <ni...@gmail.com> schrieb:
>
>
> > Hi devs - I'm hoping for a pointer or two as to how easy this might be
> > to implement in practice - I think it shouldn't be too hard, but I'm
> > not really familiar with the possibly subtle interactions.
> >
> > We build many WAR files in M2. We then merge these together at the
> > end, in order to create an 'uberwar' - this is done using the cargo
> > uberwar plugin, and from a dependency point of view, all it does is
> > that the output will contain all of the dependencies of the war
> > projects files in /lib.
> >
> > This is good - but - there's a slightly annoying problem. If the
> > output is C.WAR, made from A.WAR and B.WAR.
> > A declares it uses X:jar:1.0, and gains a number of things from that
> > transitively.
> > B declares it uses X:jar:1.1, and gains some other things from that,
> > transitively.
> > C is the merged output, and so contains X:jar:1.0 AND X:jar:1.1 AND
> > any differences in transitive deps between X:jar:1.0 and X:jar:1.1.
> >
> > If everything had been a JAR file, then maven does the clever
> > dependency analysis, and should end up with one or the other.
> >
> > So - my question is - is it possible to use the maven core to get me
> > the 'correct' result? So instead of just keeping the contents of /lib
> > from A and B, re-calculating the 'correct' files to be there.
> >
> > I have looked at the maven-dependency-plugin and
> > maven-dependency-tree, but I'm not sure I understand how to do
> > traversal from dependencies (or even if I'm looking at the correct
> > area of code to do this). I can see the ArtifactsPackagingTask in the
> > maven-war-plugin, but I'm not sure how I'd get to a MavenProject from
> > an Artifact if I needed to find dependencies recursively.. And then
> > apply the 'calculate effective dependencies' process ?
> >
> > Has anyone got any hints (or perhaps a different plugin that does
> > something similar) ?
> >
> > TIA,
> > Nigel
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
>
>
>       Machen Sie Yahoo! zu Ihrer Startseite. Los geht's:
> http://de.yahoo.com/set
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

RE: Using the dependency resolution code in a mojo

[Mark Struberg <st...@yahoo.de>]

Ouch ;)

The problem with the uberwar is, that (for what i know - i looked at the sources over 2 years ago,
so this might have changed) it has no information anymore about what kind of libraries are in the
WEB-INF/lib directory (and if those libs are maintained via maven or not). So it imho only copies
the jars on a file basis to a temporary destination directory one after the other. If you used
different versions of one and the same artifact in your dependencies, you will end up having
multiple different jars in the final WEB-INF/lib.

I had similar problems and took a somehow different way to get it done:

1.) I don't use the cargo:uberwar but the maven-war-plugin. I patched the maven-war-plugin so that
if you activate 'archiveClasses' the webclasses.jar will not only be packed into the war but also
marked as attachedArtifact. This way the webclasses.jar will also be stored in the repository and
thus may be used as dependency.

2.) I basically ignore ALL libs from the dependent wars (exclude WEB-INF/lib/*) and add
dependencies to the dependend wars AND the appropriate webclasse.jar artifacts. (Setting the
version number with properties is a good idea to not mix them up here.)
This way i get all the dependencies resolved by maven (which does all the version conflict
resolution for me, or at least I can overrule this by manually setting the dependency) and the
compilation results from the dependent wars too in my final wars WEB-INF/lib folder.

I hope my explanation makes sense to you. We use this mechanism with 3 dependency layers and up to
~10 wars (to e.g. build napsterMobile), so it's a bit complicated but definitely works ;)

LieGrü,
strub

--- Nigel Magnay <ni...@gmail.com> schrieb:

> Hi devs - I'm hoping for a pointer or two as to how easy this might be
> to implement in practice - I think it shouldn't be too hard, but I'm
> not really familiar with the possibly subtle interactions.
> 
> We build many WAR files in M2. We then merge these together at the
> end, in order to create an 'uberwar' - this is done using the cargo
> uberwar plugin, and from a dependency point of view, all it does is
> that the output will contain all of the dependencies of the war
> projects files in /lib.
> 
> This is good - but - there's a slightly annoying problem. If the
> output is C.WAR, made from A.WAR and B.WAR.
> A declares it uses X:jar:1.0, and gains a number of things from that
> transitively.
> B declares it uses X:jar:1.1, and gains some other things from that,
> transitively.
> C is the merged output, and so contains X:jar:1.0 AND X:jar:1.1 AND
> any differences in transitive deps between X:jar:1.0 and X:jar:1.1.
> 
> If everything had been a JAR file, then maven does the clever
> dependency analysis, and should end up with one or the other.
> 
> So - my question is - is it possible to use the maven core to get me
> the 'correct' result? So instead of just keeping the contents of /lib
> from A and B, re-calculating the 'correct' files to be there.
> 
> I have looked at the maven-dependency-plugin and
> maven-dependency-tree, but I'm not sure I understand how to do
> traversal from dependencies (or even if I'm looking at the correct
> area of code to do this). I can see the ArtifactsPackagingTask in the
> maven-war-plugin, but I'm not sure how I'd get to a MavenProject from
> an Artifact if I needed to find dependencies recursively.. And then
> apply the 'calculate effective dependencies' process ?
> 
> Has anyone got any hints (or perhaps a different plugin that does
> something similar) ?
> 
> TIA,
> Nigel
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 
> 



      Machen Sie Yahoo! zu Ihrer Startseite. Los geht's: 
http://de.yahoo.com/set

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org