ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruce Atherton <>
Subject Re: cullers
Date Mon, 25 Feb 2002 07:57:59 GMT
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.

Back in December, I mentioned that I was going to work on this: I got most 
of the way through it when you committed your proposal for selectors. I 
abandoned what I was doing since there didn't appear to be a need for it 

Then a couple of weeks ago, I started going through how Selectors worked 
and saw that we had somewhat different visions for how things should work:

   1) Selectors require changes to Ant1 that change the API a lot more than 
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 if 
you don't have to?

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

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.

   3) Selectors are required to use a generic interface for the attributes. 
I think that this should only be done when you absolutely have to. The more 
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 with 
Ant should be restricted in this way, it just makes things needlessly 
awkward. Why not have a single generic <task> in that case?

What I designed requires support for specific cullers within PatternSet and 
FileSet, but that seems to be sensible for the bundled cullers. Because 
Stefan requested the behaviour, I also worked on a way to add new cullers 
dynamically. I figured that the Decorator pattern was the most effective 
way to get this behaviour until I could work out whether it was possible to 
do things dynamically the Ant way with reflection (which may not be 
possible in Ant1), hence <extendcull>. The <extendcull> works exactly the 
way Selectors do, by having a fixed set of attributes. It goes farther, 
though, in that it also allows dynamic definition of new cullers within the 
build.xml file itself. It also allows dynamically loading the properties 
file that defines the definition between type and class name. I'm not sure, 
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.

Anyway, back to your question. None of these issues were fundamental enough 
for me to write a new proposal from scratch. But then, I didn't have to. I 
already had a version that had most of this stuff, I just had to complete 
it. So rather than make the modifications to the existing selector code 
which would have been more work for me, I dug out my old mods.

I think this proposal is a cleaner way to go for the reasons I give above. 
If people don't agree, no harm done. The extra effort I put in can just be 
chalked up to concrete examples of how to solve the issues I've raised. And 
if people do agree, all the better since this portion is done.

There is still more work to be done (fixing up and submitting <extendcull>, 
for example), but I won't bother unless there is a need or people decide to 
adopt the proposal.

I hope that answers your question.

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

View raw message