ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Magesh Umasankar" <>
Subject Re: cullers
Date Mon, 25 Feb 2002 21:46:55 GMT
From: "Bruce Atherton" <>

> At 04:45 PM 2/24/02 -0500, Magesh Umasankar wrote:
> >I am especially interested to understand what prompted
> >you to invest the time to create a totally new proposal -
> >did you notice glaring _fundamental_ defeciency in the
> >selectors proposal?
> A fair question. The answer is that I had already done most of the work.

An equally fair response...

>    1) Selectors require changes to Ant1 that change the API a lot more
> necessary. I had already worked out how to add the functionality without
> altering any interfaces or adding new types, so I didn't see the need for
> Selectors to do it. Perhaps this isn't a big issue but why change things
> you don't have to?

ok.  I guess I could have put the
setIncludes(Pattern[]) in a separate interface
as you have put setCullers(Culler[]), if it
became a real issue.  It is a minor point,
though a good one.

>    2) Selectors were elements of <include> and <exclude>. This struck me
> needlessly complicated. If it weren't for the historical issues, I would
> argue very strongly that <exclude> is just another name for
> and should be treated no differently. Given that <exclude> is a type of
> culler, other cullers belong at the same level.

On the same note, isn't <include> too another
name for <filenamecull>?  You cull those files
which match a specified file name pattern.

Anyway, the basic difference _conceptually_
is you ask the user to select a set of files
using <include> and then select a subset of
them. Whereas, my proposal lets the user to
select just the set of files that is needed.

Let us say, I want to include all files
that have a size > 4 K but exclude those
that are readonly with names beginning
with "Test" with extension "jar" whose size
is greater than 5K

    <include name="**/*">
        <selector type="size"
    <exclude name="**/Test*.jar">
        <selector type="size"

How would you do that in your proposal?

> More than that, differentiating the behaviour of two sets of selectors
> introduces complexity that is hard to understand. When it is in an include
> block, it acts to select certain files (and cull the rest), but when it is
> in an exclude block it is a culler of a culler. Even if you buy that this
> is a desirable behaviour, and I don't because I think it makes things hard
> to grasp, why the artificial limit on only allowing multiple levels in one
> particular type of selector, the <exclude>? Why not select from the files
> selected by any of the other selectors, ad infinitum? Scary thought, no?
> That's why I'm not fond of selectors in exclude.

I don't see it as awfully confusing.  But
again, I can understand your point...

>    3) Selectors are required to use a generic interface for the
> I think that this should only be done when you absolutely have to. The
> information you can give to a user to do the right thing, the better off
> you and they are. It makes no sense that the cullers/selectors bundled
> Ant should be restricted in this way, it just makes things needlessly
> awkward. Why not have a single generic <task> in that case?

We do not have a generic <task> because the
mechanism is in place to allow user-defined
tasks to have its own attributes/elements
without having to touch Ant's core.  However,
the same cannot be said for <selector> or
<culler> in Ant1's context.

Would it be fair if we say that Ant's core tasks
will be able to have well defined attributes
and elements, but a custom defined task
can only have attr1, attr2 and elem1, elem2?

I am not saying I am happy with the generic
way in which I have implemented it - I recognize
though that there is no _clean_ solution
in Ant1, where we can have Ant's selectors and
user-defined pluggable selectors match up in

> though, in that it also allows dynamic definition of new cullers within
> build.xml file itself. It also allows dynamically loading the properties
> file that defines the definition between type and class name. I'm not
> but it didn't look to me like Selectors would do these things. It seemed
> like a user would have to edit the properties file inside the ant.jar to
> add new selectors. I may have misunderstood.

Yes, that had been pointed out earlier.
I was planning to rework it such that it
could be defined from build.xml as well,
just as you say youhave done it.

> I hope that answers your question.

That does; thanks!


* So what's the speed of dark? *

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

View raw message