ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Archie Cobbs <>
Subject Re: inline resolve mode
Date Tue, 23 Jun 2009 14:41:11 GMT

First of all, every module must have an ivy.xml file to describe it.

If what you want to resolve is a module, then you can do that with the
inline ant tasks. Then you are specifying the module name and letting ivy
(using your ivy settings) locate the corresponding ivy.xml file, process the
dependencies, etc.

If what you want to do is define a new module inline (including one or more
dependencies) and then resolve it, then you are essentially trying to
"inline" and ivy.xml file and I don't think ivy currently supports that. I
don't see why you would need the ability to do this anyway... you can always
just put the module meta-data into a local ivy.xml file and then refer to

Not sure what you're trying to do but I typically do this kind of thing for
software projects. Each project has it's own ivy.xml that defines
configurations like "compile", "test", etc. When I need to build the
classpath for the "javac" task, I use an inline call to <ivy:cachepath> or
whatever to get the JARs associated with the "compile" configuration, etc.

Hope this helps.


On Tue, Jun 23, 2009 at 1:06 AM, Shawn Castrianni <> wrote:

> I need a way to resolve dependencies of a module WITHOUT an ivy.xml file.
>  It looks like inline mode is what I want, however, I am not sure about
> something.  An ivy.xml file can specify more than 1 dependency, each with
> its own revision constraint and configuration specification.  It looks like
> the inline resolve ant task only allows 1 dependency to be specified with 1
> configuration and 1 revision constraint.  Therefore, it seems that inline
> resolve is not a complete replacement for an ivy.xml file.  Am I supposed to
> make multiple separate calls to inline resolve for each dependency I have
> that would normally be listed in an ivy.xml file?  If so, how does the
> conflict resolution work since each inline resolve operation would not know
> about the previous inline resolve operation to properly resolve conflicts??

Archie L. Cobbs

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