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 Thu, 04 Mar 2010 22:20:47 GMT
To expand on the possible syntax to applying this filters concept at the
resolve level rather than the post-resolve level, you could have in the
module descriptor XML schema a filters element that follows configurations:
<filters>
  <filter name="static" />
  <filter name="dynamic" />
</filters>

Then you'd be adding a filters attribute to the elements that currently have
a conf attribute (or child element):
<artifact name="libzlib" type="lib" ext="lib" conf="compile,release"
filters="static"/>
<artifact name="zlib" type="lib" ext="lib" conf="compile,release"
filters="dynamic"/>

On the dependency element in the dependent module:
<dependency org="myorg" name="mylibs" rev="1.0"
conf="default->compile,release" filters="static" />

The nice thing here is that, in keeping with the Ivy contract, the dependent
module is oblivious of what artifacts are actually being obtained.

The ivy:resolve task would also introduce a filters attribute.

I'm sure I'm missing something critical.

On Thu, Mar 4, 2010 at 2:11 PM, Mitch Gitman <mgitman@gmail.com> wrote:

> Shawn, this feature request is subtly different from configuration
> intersection in that it's being specified on the depended-upon module rather
> than on the dependent, which is the case with configuration intersection.
>
> Remember last year there had been some discussion of introducing
> configuration intersection on the dependency, the publishing module, as a
> way of avoiding having to write arbitrary compound confs. I'd supported this
> idea, but I realize why perhaps it's not a good idea--because it's
> implicitly introducing an extra interface that nine times out of 10 the
> publishing module doesn't want.
>
> Frankly, I do think there's value in introducing a concept like a filter,
> some extra parameter that can further weed out artifacts beyond what confs
> do. This is not unlike the platform attribute proposal Jeffrey Sinclair
> made, to which dek577 here linked.
>
> The only modification I would make to this feature request, and it's a
> significant one, is that this concept of a filter be introduced at the conf
> level, so that it's available when specifying dependencies or when doing an
> ivy:resolve--rather than its being associated with post-resolve tasks like
> ivy:retrieve and ivy:cachefileset. I think you get into an un-kosher mixing
> of concerns when do additional weeding out with post-resolve tasks. Probably
> the syntax of this wouldn't be that complicated:
>
> <artifact name="libzlib" type="lib" ext="lib" conf="compile,release"
> filters="static"/>
>
> And on a dependency, you could specify filters in addition to conf.
>
>

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