Peter writes:
> Someone already has tackled it for Ant1.x - have a look at
> the mail on ant-dev
>
> [SUBMIT] Selector API Implementation
> Date: Sat, 12 Jan 2002 21:02:40 -0500
> From: "Magesh Umasankar" <[EMAIL PROTECTED]>
>
> However it still follows the old style. I would love to see
> what you thought
> of it. It is a patch against ant1.x so can't have all the wiz
> bang features
> that would be possible in a more controlled container but it
> is a great start.
Well, this implementation adds the requested features, but I think have trouble
with the approach because all you have to work with is "value" and "operation".
Some types don't need the "operation" -e.g. permission. Some types need more
than one "value". What if I want a "between" selector that needs two values? Of
course, I could always do a "before" and an "after" but this is the first
two-value operation I can think of.
Plus, its not entirely clear to me how I'd add my own FileSelectors using this
api. With an implementation based on registering new data types, I could add
them simply by pulling in a new antlib that declared that file selector type.
> > Each implementor of FileSelector would be able to define specific
> > attributes that needed to be set -- no generic "operation", "value"
> > attributes that make sense for one selector type but not
> another. This
> > would also greatly simplify extending and providing your
> own custom file
> > selector - just subclass FileSelector, add the task
> definition to your
> > build file, and away you go -- the ant execution engine
> should take care of
> > the rest.
> It has been suggested before and I think that was the initial
> XML API I
> proposed but it was -1'ed by other committers. However I
> still think it would
> be useful ;)
>From looking at the Mutant design notes, it looks like Conor is supporting it,
>so he'll have trouble with this as well if there's someone opposed to it. I'd
>like to hear from whoever -1'ed it, because I don't see the downside.
I mean, obviously the current reflection mechanism in Ant is limited because
its based on hardcoding the types available to be added. Just look at
org.apache.tools.ant.taskdefs.condition.ConditionBase! It has:
public void addAvailable(Available a) {conditions.addElement(a);}
public void addChecksum(Checksum c) {conditions.addElement(c);}
public void addUptodate(UpToDate u) {conditions.addElement(u);}
public void addNot(Not n) {conditions.addElement(n);}
public void addAnd(And a) {conditions.addElement(a);}
public void addOr(Or o) {conditions.addElement(o);}
public void addEquals(Equals e) {conditions.addElement(e);}
public void addOs(Os o) {conditions.addElement(o);}
public void addIsSet(IsSet i) {conditions.addElement(i);}
public void addHttp(Http h) {conditions.addElement(h);}
public void addSocket(Socket s) {conditions.addElement(s);}
public void addFilesMatch(FilesMatch test) {conditions.addElement(test);}
Each of these arguments implements Condition. A single
public void addCondition(Condition c) {conditions.addElement(c);}
should have sufficed. And the system would be more extensable because I could
add my own conditions, such as RandomChance :-), in a separate antlib without
having to modify ConditionBase. Plus, the And, Or, Equals, etc. could all be
(rightly, IMHO) implemented as Types rather than Tasks - it seems they are only
implemented as tasks due to implementation inheritance needs of all the
addXXX() methods. If you had one simply addCondition() method, you could simply
duplicate that in the ConditionBase and the ConditionTask classes.
Now, when I sent my original note, it was clear to me that this would mean
changing the IntrospectionHelper to separate the concept from a type's name in
the build file, to the internal type that's being used, be it an interface or a
superclass. In Ant1 we don't have that capability because all the
defaults.properties file only allows definition of the XML element name and the
class, and we really don't want to go trying to guess what it might also be
used as (e.g. walking the inheritance hierarchy and all interfaces implemented?
ugh) But with a deployment descriptor, we could extend the proposed typedef to
supply the type it should be "cast" to, if any. For example
<typedef name="path" classname="org.apache.tools.ant.types.Path"/>
<typedef name="add" cast="condition"
classname="org.apache.tools.ant.taskdefs.condition.Add"/>
<typedef name="or" cast="condition"
classname="org.apache.tools.ant.taskdefs.condition.Or"/>
<typedef name="not" cast="condition"
classname="org.apache.tools.ant.taskdefs.condition.Not"/>
The first item would work as is today - IntrospectionHelper would look for
addPath(). The last three would work slightly differently, instead of looking
for addAnd(), addOr(), addNot(), etc. it would look for addCondition() in all
three.
Of course, we don't currently have typedef and DD's in Ant 1.x, but as I and
others have proposed before, there's no reason we couldn't add <antlib> and
DD's now. The big reason it has been -1'ed before seemed to be a lack of
consensus on what the Ant2 <antlib> and DD's would look like, and a desire not
to hack something now & change it later. Have we had enough time to mull this
over that a consensus is building as to how the DD's for the libs would look
and work?
Barring that, the only way to make types more extensible under Ant1.x would be
to hack it in code & allow the type class to specify the cast. I'm not sure
I'd like that, but it may not be altogether bad since you'd have in code the
"addCondition()" method, and somewhere else - in code - the "condition"
property specified - theoretically when you implement a type, you know what
"add/set" methods should get called. Anyway, if we did this, DataType would
have to add a "public String getProperty()" method that would return the
property to use when looking for an "add" or a "set" method. The existing
"name" of the type would only be used for parsing the XML. This last point is
valuable as well, in the hypothetical case where you have a non-xml source for
your project.
Tim
> -----Original Message-----
> From: Peter Donald [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, January 22, 2002 2:31 AM
> To: Ant Developers List
> Subject: Re: Ant 1.9 actionlist & Selector API
>
>
> On Tue, 22 Jan 2002 08:37, Tim Dawson wrote:
> > I apologize in advance if this is a duplicate send or the topic has
> > otherwise been discussed in the last week. I recently switched email
> > accounts and hadn't remembered to re-subscribe under the
> new address.
> >
> > http://jakarta.apache.org/ant/ant2/actionlist.html#selector states:
> >
> > The selector API is one such mechanism to do this. The
> selector API will
> > allow you to build file sets based on criteria other than name. Some
> > possible criteria would be
> > * Is the file readable?
> > * Is the file writeable?
> > * What date was the file modified on?
> > * What size is the file?
> > * Does the contents contain the string "magic"?
> >
> > If we end up supporting a VFS then we could expand the
> number of selectors
> > considerably. A mock representation that has been proposed
> before is the
> > following. Of course this is subject to change as soon as
> someone wants to
> > tackle this action ;)
>
> Someone already has tackled it for Ant1.x - have a look at
> the mail on ant-dev
>
> [SUBMIT] Selector API Implementation
> Date: Sat, 12 Jan 2002 21:02:40 -0500
> From: "Magesh Umasankar" <[EMAIL PROTECTED]>
>
> However it still follows the old style. I would love to see
> what you thought
> of it. It is a patch against ant1.x so can't have all the wiz
> bang features
> that would be possible in a more controlled container but it
> is a great start.
>
> > Each implementor of FileSelector would be able to define specific
> > attributes that needed to be set -- no generic "operation", "value"
> > attributes that make sense for one selector type but not
> another. This
> > would also greatly simplify extending and providing your
> own custom file
> > selector - just subclass FileSelector, add the task
> definition to your
> > build file, and away you go -- the ant execution engine
> should take care of
> > the rest.
>
> It has been suggested before and I think that was the initial
> XML API I
> proposed but it was -1'ed by other committers. However I
> still think it would
> be useful ;)
>
> --
> Cheers,
>
> Pete
>
> *--------------------------------*
> | Every rule has an exception, |
> | except the rule of exceptions. |
> *--------------------------------*
>
>
> --
> To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
>
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
