ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <>
Subject Re: What is going on in ANT1.x
Date Thu, 07 Feb 2002 06:55:00 GMT
On Thu, 7 Feb 2002, Jose Alberto Fernandez <>

> I hope I can get your support if you think any solution I offer is
> an alternative.

You do.

> From: "Stefan Bodewig" <>
>> On Wed, 6 Feb 2002, Jose Alberto Fernandez
>> <> wrote:

>> > One of the problems I see, is that when code gets put in by
>> > committers, in very few occacions other review the code.
>> I hope (and believe) that this is not true.
> Are you follwing every aspect of Peter's ANT2 proposal?

Honestly, I don't.  Same for Conor's, just for the record.

> If we decide to based ANT2 on his proposal, do you think we will all
> grasp every aspect of it to be able to catch every possible issue
> before a release goes out?

At least I will take the time to compare each proposal that is there
with the list of features we've agreed upon and declined.  And no
matter which codebase we base Ant2 on, it can always be changed.  At
least after a codebase has become the basis of Ant2, it is ant-dev's
code and not Peter's or Conor's or whoever's.  I know that the code
inside the proposal hierarchy is ant-dev's right now, but I doubt any
committer has the bandwidth to follow any proposal completely.

> I think the same thing happens with committers written code.

I read all commit messages to the main branch, I bootstrap and run all
tests after each update - and thanks to Steve, Stephane, Erik and
Magesh we are covering an increasing amount of Ant with testcases
every day. 

> But the point of the matter is that once it is committed, the burden
> is on those that think that soomething is not quite right. Which is
> different than for non-committers.

True - this is where committers control committers.  I expect from the
people I vote in as committers that they do so, and in my experience,
this happens.

>> > Another solution which I think could be backward compatible is to
>> > have DataType extend Task
>> This would work for the data types shipping with Ant, but there is
>> nothing in the code that forces a data type to extend DataType.
> Now, this is real news to me. I had no idea that there were no type
> constraints what so ever for DataTypes.

It has always been that way.  In the beginning, DataType wasn't even
there, it was added as a base class to factor out common functionality
from Path, FileSet and PatternSet.

> We could define a DataTypeTaskAdaptor which takes an object, defined
> as a datatype, and produces a Task that can be passed to the
> TaskContainer.

If an element is not known at parser time, you don't know whether it
will be task or a data type later - how would you address this?

Isn't UnknownElement exactly this type of adaptor?  It inherits from
Task and manages data types at execution time as well.


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

View raw message