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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[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] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > Jetzt Mails schnell in einem Vorschaufenster überfliegen. Dies und viel mehr bietet das neue Yahoo! Mail - www.yahoo.de/mail --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
