Pete, I'm speaking a little off-the-cuff here because I don't quite have a handle on your constraints, but this strikes me as a case where you're using Ivy but you're not quite trusting Ivy.
For one thing, if the WAR in question is being built by your own build system, then you have control over it. Instead of using a package resolver to go into the JARs in WEB-INF/lib/, why not give your WAR project an ivy.xml and make all those third-party modules dependencies? For example: <dependency org="com.sun.jersey" name="jersey" rev="1.1.4" conf="runtime->*" /> This is presuming you have a conf called "runtime". You can then do an ivy:cachepath against the "runtime" conf. Ivy's all about *transitive *dependency management, but resolving the JARs that have been physically placed in a WAR is a case of nipping the transitivity in the bud. The other thing that suggests you're not quite trusting Ivy is that you're trying to include artifacts in your dependencies. Your dependent module's ivy.xml should really be oblivious of the particular artifacts in its dependencies. That's what the dependencies' own Ivy confs are there for--to provide an abstraction layer to encapsulate the various artifacts being published by those Ivy module. This may be a case though where your hands are tied because you don't control the Ivy files for your dependency modules. I didn't quite understand the line: "The module that has the dependency is in a separate application (even separate SCM system) and I am consuming the WAR as such." Both these observations are predicated that you're going to go to the trouble to create and publish Ivy modules with meaningful ivy.xml files for your third-party dependencies. Obviously, my opinion is this is worth it, even if it means changing the way you publish your upstream applications. On Mon, Nov 16, 2009 at 6:17 AM, Peter Hale <[email protected]> wrote: > Mitch, > > > Thanks for replying. > It does appear that I should be specifying com.sun.jersey as the org, but > in > our case the WAR file in question is produced by our build system and > contains all of the pieces (JSR-311, asm, jersey jars, etc.) required by > our > application. The module that has the dependency is in a separate > application > (even separate SCM system) and I am consuming the WAR as such. I am using a > packager resolver to expand the WAR so I can have access to its contents. > What I need is the set of jars as a class path (using ivy:cachepath), but I > do not want to specify the artifacts explicitly in the dependency. > > This is why I want to use the matcher attribute for the include. > > Thanks, > > Pete > >
