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

Reply via email to