Replies inline. If it sounds like I'm going back and forth on what you're suggesting, I am a little bit.
On Tue, Mar 2, 2010 at 2:14 PM, dek577 <[email protected]> wrote: > > 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 > > I'll cite another post from that same thread in a moment. > 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. > > Bear with me while I possibly oversimplify your problem for discussion's sake. From my purist/orthodox perspective, I would say your statement here suggests you're resisting Ivy's philosophy where doing so doesn't gain you anything. Ivy confs are there to separate interface and implementation. The published confs are the interface being presented by the module. The artifacts are the implementation being encapsulated. The whole point of Ivy confs is that you DON'T want to know the particular artifacts being published. If the confs being published don't precisely enough reflect the artifacts you need--and if configuration intersections specified on the dependent modules don't do the trick either--then why not create more precise confs on the module, even if it means creating arbitrary compound confs representing combinations of other confs? > 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. > > So why not express runtime+release on the consuming module's dependency or on the ivy:resolve? Then ivy:cachefileset can use whatever's been resolved. Now, back to that earlier thread, there is a post from Maarten Coene that expresses an openness to much the same thing I'm resisting: http://mail-archives.apache.org/mod_mbox/ant-ivy-user/200908.mbox/%[email protected]%3e Quote: "But maybe you could make this 'platform' attribute custom/extra attribute and modify the retrieve/cachepath task to make it possible to filter on these extra attributes as well, which is a more general like for instance requested in https://issues.apache.org/jira/browse/IVY-439 " Perhaps it would get too complicated to express the equivalent of that filtering parameter strictly via confs using the existing confs syntax. If that's the case, though, I would rather see the extra filtering parameter expressed via a new syntax on confs rather than on post-resolve tasks. I don't know what the status is on the new feature Maarten effectively proposes.
