ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Enderling <>
Subject [Ivy] Support for generic filters (and download-option) on Ivy's resolve + post resolve tasks
Date Tue, 28 May 2013 10:35:37 GMT

we would like to use Ivy in our build and deployment process.

In order to implement this I'm missing functionality on the - already very versatile - Ivy
resolve task: While the ResolveOptions class allows arbitrary filters to be set, Ivy resolve
only allows to specify the type attribute, which will always result in an instance of ArtifactTypeFilter
in the resolve options. I would like to use a different (custom) filter implementation here.

Unfortunately the method IvyResolve.getResolveOptions(Ivy, String[], IvySettings) is private,
so I cannot add another filter simply through subclassing IvyResolve in a custom Ant task.

I propose to make it possible to add a single implementation of org.apache.ivy.util.filter.Filter
as nested element of IvyResolve, as well as IvyPostResolveTask. (A single filter would be
sufficient, as we can simply provide compounds like the AndFilter and OrFilter.) For compatibility
the type attribute must still be supported and either be combined with an additional custom
filter (by logical and) or only one of them can be used. 

Filter should generally extend Ant's DataType to enable reference-handling and be defined
as global Ant types with typedefs. (Which means the element for the OrFilter cannot be called
simply 'or', but must be called 'orfilter', but this seems more plausible to me than what
Ant does with conditions and file selectors.) This way anyone is free to add custom filters.

For all existing implementations of org.apache.ivy.util.filter.Filter there should be an accompanying
wrapper, that basically does the same but extends from Ant's DataType class. (We cannot simply
change them, since this would tie using Filters to having Ant in the classpath.)

Another small thing is, that ResolveOption's download field cannot be set to false through
IvyResolve. I would also like to add an attribute to that. (Setting download to false can
theoretically be emulated by providing a type-attribute with a type that is guaranteed to
not be used in artifact declarations - like type="(none)", but as you would probably agree
this is only a hack.) 

What do you think?

If you generally agree to include this in the next release, I can submit an according patch.

Our concrete use case for filters is that we mark platform specific artifacts (we publish
platforms for different platforms inside the same Ivy module) with an extra attribute, containing
the target platform. (I know that there are other proposed ways to solve the problem of platform
specific artifacts, like using Ivy configurations, but just for a minute, take our solution
to this as settled.) During resolve I only want to download those artifacts, that match the
current platform (or are platform independent). Therefore I would like to use an artifact
filter that can compare the value of an extra attribute with an expected value in a certain

The use case for setting the download attribute to "false" is to use the resolve task to only
gain insights over the dependency graph of modules (like by reusing the resulting ResolveReport
in a custom post resolve task), not wanting to fiddle with artifacts at all.

Best regards,
Tim Enderling

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message