ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <>
Subject Re: TaskContainer and nested data-types
Date Sun, 10 Nov 2002 09:49:53 GMT
Stephane Bailliez wrote:

>> > I cannot see any reason why they could not. Except enforcing data types
>> > definition outside for style.
>> +1.
> For what is your +1 here ?
> I was understanding in your previous mail that you wanted data types to be
> possible in the container. Is that correct or should I take fresh air and
> reread your mail ?

It is correct. I would like the distinction between data types and 
tasks to be removed.

> [...]
>> If a majority of ant committers don't feel it's a good idea or worth
>> the pain - then it shouldn't be done.
> It's not the problem.
> I agree we can spend our time vetoing and see them flying around but this
> is the way I see things. I'd rather let people move on. I'm just pointing
> out that raising 'backward compatibility' flag only when it suits is no
> good.

"Backward compatibility" is one important issue to consider - but not
the only one. In this case - I don't think anyone would be affected.
For javac default debugging - I think the benefits of changing the
default justifies the backward incompatibility.

In all cases - a PROPOSAL is the best way to move forward. 
Not sure how the 'veto' is related with this discussion - a proposal
is not a code change, so a vote against is not a veto.

> I would like you to explain me how you could possibly take the
> responsability of enforcing data types 'outside' the container knowing
> that it would break build files and at the same time not agreeing to
> change the javac debug flag back to normal ?
> ok, this is a bad example for you since you agree on both sides but I
> think you get the idea. :)

I don't get the idea, sorry.

My point is that for any change that is important enough ( and breaking
backward compat is important, as well as changing the build.xml 
semantics ) it is best to have a formal proposal and a majority vote first.
It's not a waste of time.


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

View raw message