ant-dev mailing list archives

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


> 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
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?

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
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.

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

<fileset>
    <include name="**/*">
        <selector type="size"
            operation="greater-than"
            value="4K"/>
    </include>
    <exclude name="**/Test*.jar">
        <selector type="size"
            operation="greater-than"
            value="5K"/>
    </exclude>
</fileset>

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
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?

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
syntax.

> 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.

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!

Cheers,
Magesh

********************************
* So what's the speed of dark? *
********************************



--
To unsubscribe, e-mail:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>


Mime
View raw message