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 <[EMAIL PROTECTED]> 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 <[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.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 <[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] > >
