ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From dek577 <>
Subject Re: advanced ivy retrieve syntax
Date Tue, 02 Mar 2010 22:14:18 GMT

I'm not worried about the duplicate artifact issue. ivy:retrieve supports the
symlink attribute that prevents duplicate copies. If the objection is
philosophical and you want to use ivy:cachepath instead, then my question
directly extends to that as well. Could you use advanced intersections and
negations to specify the configurations on ivy:cachepath (or any post
resolve task).

I'm using ivy for native multi-platform dependency management of artifacts
x64, x86, debug, release, etc, dlls, libs, exes. A common example is a
c,c++, or fortran library that publishes several different flavors of
artifacts (debug, release, static, dynamic, headers, etc) for different
platforms and compilers. Almost every single module I have has more than a
one published artifact and a small handful of configurations. The
granularity of the module is about as small is it could be. If you want to
see examples take a look at:

There is a rich syntax for defining the dependency relationship between
modules. The problem is that when I'm compiling or packaging the code, I
need to know the internal configuration structure (which dependent artifacts
belong to a particular configuration) to package and build correctly. 

I could hard code the information into my ant script and conditionally
remove those resolved items that I don't need (such as the debug versions
for a release build), but I'd much rather ask ivy to automatically find me
all the artifacts I depend on that are in the intersection of the 'runtime'
and 'release' configurations. 

Mitch Gitman wrote:
> dek577, since no one else has gotten back to you yet, let me take a stab
> at
> this.
> I'm one to argue that, even though there's nothing literally wrong with
> using ivy:retrieve, its use suggests that you haven't quite fully embraced
> Ivy. The ivy:retrieve task is creating duplicate copies of your artifacts,
> which already exist in the Ivy cache. And those copies are inevitably
> going
> to be used to manually create a path or fileset when you could just use
> ivy:cachepath or ivy:cachefileset directly against the results of
> ivy:resolve. Plus, you invite potential inconsistencies between your
> destination directory for retrieves and the contents of the Ivy repo where
> the latter should be your artifact location of record.
> Setting that concern aside, what strikes me as an indication of not fully
> embracing an Ivy paradigm is your wish to grab a subset of your
> dependencies. This wish suggests that your dependencies are not
> fine-grained
> enough. The Ivy-centric answer, IMO, is to make your dependencies
> finer-grained--give those dependencies more precise Ivy confs. If you
> can't
> because you don't control those dependencies, then this is an argument for
> rethinking how you consume them.
> To offer an analogy, suppose you have two power tools: a chainsaw and a
> drill. And someone explains to you what each tool is used for. And you
> say,
> "But what if I want to do drilling with the chainsaw? How would I do
> that?"
> Well, you wouldn't. That's what you have the drill for.
> On Mon, Mar 1, 2010 at 3:54 PM, dek577 <> wrote:
>> Does the ivy:retrieve ant task support more advanced configuration
>> specifications similar to the configuration mappings, intersections, and
>> negations described here:
>> I'm interested in doing a retrieve similar to the following:
>> <task name="retrieve">
>> <ivy:retriive conf="runtime+release"
>> pattern="${staging.dir}/[module]-[revision]/[artifact](.[ext])"/>
>> </task>
>> that grabs a subset of the dependencies.
>> -Thanks
>> --
>> View this message in context:
>> Sent from the ivy-user mailing list archive at

View this message in context:
Sent from the ivy-user mailing list archive at

View raw message