Thanks for that.
I ended up by patching the cargo uberwar behaviour and adding
a true
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"
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]> schrie
Ah - interesting - I hadn't considered the archiveClasses part. Does
it then get it's own pom file with jar ? 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' fil
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
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 'uber
