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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
Machen Sie Yahoo! zu Ihrer Startseite. Los geht's:
http://de.yahoo.com/set
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
