ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <>
Subject Re: TaskAdapter and execute()
Date Sat, 02 Mar 2002 21:02:36 GMT
On Sat, 2 Mar 2002 18:39, Adam Murdoch wrote:
> > Lack of control for task writer. ie Theres no way for a taskwriter to
> > explicitly state than they only want to expose feature X as an
> > element - not
> > an attribute.
> We need meta-info.  Not necessarily for this issue, but it would certainly
> solve the problem.

I don't think we should be requiring task writers specify such meta-info to 
write a simple task.

> I don't think we should be changing our configuration model just because it
> makes documentation generations a little tricky.

It is not for this reason that I suggest it. Documentation just made me look 
at it and made it obvious to me that it was too complex. 

Just in case you didn't realize but Myrmidon used to be pure bean based at 
one stage but that became too complex for task writers and thus I reverted to 
ant patterns. ie At one version it used zero adders or creators but used 
constructs like

public void setBlah( Blee[] blees );

> > After looking at it again I don't think it makes tasks easier to
> > write. It
> > removes control from Task writers and the benefit is minimal.
> > Personally I
> > would not mind something like
> >
> > void setClassPath( Path p )
> > {
> >   addClassPath( p );
> > }
> The benefit isn't minimal.  You're getting:
> * One less method to write.

That I don't consider painful - especially when comparing it to writing 
meta-info that you sugested.

> * Multiplicity checking.

Nice but still minimal advantage IMHO.

> * A clearer semantic on your object interfaces.  With the Ant 1 behaviour,
> the meaning of setX() is misleading when property X is multi-valued - it
> doesn't *set* the property, it *adds* a value to the property.

Ants pattern are not beanish but antish and people learn the difference fast 
so I don't think it is a huge problem.

> I think meta-info is the answer here. 

I don't - meta-info is a workaround for something that isn't clear enough.

> We've gotten to the point where we
> have to guess the task writer's intention.  Let's give 'em a way to make it
> explicit.  So, how about we leave things how they are for now, and get a
> basic meta-info framework happening, then sort the mapping out.  We could
> even go as far as letting the task writer specify which style of method
> mapping to use.

I have already started a info descriptor system. Will commit it sometime 
soonish when I start testing it out ;)



Whatever you do will be insignificant, 
but it is very important that you do it. 

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

View raw message