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 <[email protected]> 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. > >
