ant-dev mailing list archives

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

> On Wed, 6 Feb 2002, Jose Alberto Fernandez <>
> wrote:
> > Yeap, it would have been nice if the list had had a
> > chance to discuss the implementation before it was
> > committed.
> This is kind of difficult as we are not talking about a single commit.
> You may remember that I've sent both the original implementation of
> IntrospectionHelper and the RuntimeConfigurable/UnknownElement stuff
> to the list before committing it - it is a long time ago, but you've
> been here, I know that.
> Back then, the code was not as brittle as it is right now - things
> have evolved over time and features have been added or stuff got
> rewriten to account for bugs and all that.  You know that, I'm sure.

Well, if I remember correctly, and I may not. The main problem we had have in this area
is that DataTypes where never really taken into account seriously. It took more than
two releases for people to even realize that there was no way to declare a datatype
outside of a target, and so on and so forth.

> At some point there is no other way to get rid of cruft than to
> completely rewrite what started as something simple and turned into a
> monster.
> I see this rewrite happen in Ant2 as I'm afraid you cannot rewrite it
> without breaking compatibility.  If Adam finds a way, I'll give him
> all support he can get.

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

> > 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? I really cannot follow
so many files being checked in. 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?

I think the same thing happens with committers written code. We trust you
guys and therefore I do not think people are so keen at doing codes reviews.
The code is already in and hence unless you can come up with an evident issue,
it is difficult (at least for non committers) to do anything about it.

As an example, like 2 month ago or more, Peter made a change in ANT2
where it rename getTaskName() to getName(). At that time I mentioned
that by doing that it may cause a conflict on tasks, but since it was not obvious
at the time the change stayed. A few days ago, another change was introduced
for what it seem to be exactly the kind of issues I was refering about.
Maybe he was aware of this from the begining, may be not. 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.

> > Another solution which I think could be backward compatible is to
> > have DataType extend Task and provide, possibly final,
> > implementations for all the methods required by Task making them
> > harmless.
> 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. As you said, I have been here for a very long time
and I had never heard of datatypes on such a light.

Was this ever by design? Then all the container model is really broken.

On the light of this revelation, let me put on the table an alternative solution:

We could define a DataTypeTaskAdaptor which takes an object, defined as a 
datatype, and produces a Task that can be passed to the TaskContainer.
This will be completelly internal, will work in the same way as TaskAdaptor
for beans, and will generalize the solution to this ugly stuff.

To me this is not an academic issue, I would like to push ANT1 further and this
kinds of problems break any consistency in the product.

Jose Alberto

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

View raw message