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: http://www.cooljeff.co.uk/2009/08/01/handling-native-dependencies-with-apache-ivy and http://mail-archives.apache.org/mod_mbox/ant-ivy-user/200908.mbox/%[email protected]%3e 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 <[email protected]> wrote: > >> >> Does the ivy:retrieve ant task support more advanced configuration >> specifications similar to the configuration mappings, intersections, and >> negations described here: >> http://ant.apache.org/ivy/history/latest-milestone/ivyfile/dependency.html >> >> 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: >> http://old.nabble.com/advanced-ivy-retrieve-syntax-tp27750721p27750721.html >> Sent from the ivy-user mailing list archive at Nabble.com. >> >> > > -- View this message in context: http://old.nabble.com/advanced-ivy-retrieve-syntax-tp27750721p27761908.html Sent from the ivy-user mailing list archive at Nabble.com.
