ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mitch Gitman <>
Subject Re: Help understanding dependency element include w/ matcher
Date Mon, 16 Nov 2009 17:29:08 GMT
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
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 <> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message