ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tim Dawson" <tdawso...@yahoo.com>
Subject RE: Ant 1.9 actionlist & Selector API
Date Wed, 23 Jan 2002 21:42:16 GMT
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" <umagesh@apache.org>
> 
> 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:peter@apache.org]
> 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" <umagesh@apache.org>
> 
> 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:ant-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: 
> <mailto:ant-dev-help@jakarta.apache.org>
> 


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


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