ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mitch Gitman <mgit...@gmail.com>
Subject Re: advanced ivy retrieve syntax
Date Tue, 02 Mar 2010 23:28:08 GMT
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 <dek577@gmail.com> 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/%3C45f3b7570908032325s74573fc4k2c8de6522ea700b9@mail.gmail.com%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/%3C182251.97962.qm@web30803.mail.mud.yahoo.com%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.

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