Hi Tim, I like the idea, so a patch would be grealty appreciated.
There already exists a very old JIRA issue for this, so you can attach your patch to that one: https://issues.apache.org/jira/browse/IVY-439 thanks, Maarten ________________________________ Van: Tim Enderling <t.enderl...@intershop.de> Aan: 'Ant Developers List' <dev@ant.apache.org> Verzonden: dinsdag 28 mei 12:35 2013 Onderwerp: [Ivy] Support for generic filters (and download-option) on Ivy's resolve + post resolve tasks Hi, 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. Background: 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 way. 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: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
