Mailing-List: contact dev-help@ant.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Ant Developers List" <dev@ant.apache.org>
Received-SPF: pass (nike.apache.org: domain of T.Enderling@intershop.de
 designates 195.110.60.6 as permitted sender)
From: Tim Enderling <T.Enderling@intershop.de>
To: "'Ant Developers List'" <dev@ant.apache.org>
Subject: [Ivy] Support for generic filters (and download-option) on Ivy's
 resolve + post resolve tasks
Thread-Topic: [Ivy] Support for generic filters (and download-option) on
 Ivy's resolve + post resolve tasks
Thread-Index: Ac5bjxg7tq8n4RjQQuWr/z2vntzdvA==
Date: Tue, 28 May 2013 10:35:37 +0000
Message-ID: 
 <81454BDF21961D4FA3014B5291F809142FDC3331@jenmbs02.ad.intershop.net>
Accept-Language: de-DE, en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

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 arbitra=
ry filters to be set, Ivy resolve only allows to specify the type attribute=
, which will always result in an instance of ArtifactTypeFilter in the reso=
lve options. I would like to use a different (custom) filter implementation=
 here.

Unfortunately the method IvyResolve.getResolveOptions(Ivy, String[], IvySet=
tings) is private, so I cannot add another filter simply through subclassin=
g IvyResolve in a custom Ant task.=20

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 IvyPostR=
esolveTask. (A single filter would be sufficient, as we can simply provide =
compounds like the AndFilter and OrFilter.) For compatibility the type attr=
ibute must still be supported and either be combined with an additional cus=
tom filter (by logical and) or only one of them can be used.=20

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 a=
nd file selectors.) This way anyone is free to add custom filters.=20

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

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

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 artifac=
ts (we publish platforms for different platforms inside the same Ivy module=
) with an extra attribute, containing the target platform. (I know that the=
re are other proposed ways to solve the problem of platform specific artifa=
cts, like using Ivy configurations, but just for a minute, take our solutio=
n to this as settled.) During resolve I only want to download those artifac=
ts, that match the current platform (or are platform independent). Therefor=
e I would like to use an artifact filter that can compare the value of an e=
xtra attribute with an expected value in a certain way.

The use case for setting the download attribute to "false" is to use the re=
solve 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-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org