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:39:39 GMT
Dominique Devienne wrote:

> Oh boy, that didn't sound like I'll be able to put a <path> inside an
> <if>/<switch> any time soon, didn't it... --DD

My +1 was for "eliminate the distinction between task and type, there's no
reason to not be able to put <path> inside if"

And my opinion was that if you want it to happen, all you need to do
is send a [PROPOSAL] to be voted by ant committers. If it gets more 
+1 than -1 and at least 3 +1 - then the proposal can be implemented.

At least in [embed] I tried to eliminate most of the differences between
task and type - so if you don't make the proposal now, I'll make it
later. But the only way to move forward ( IMO ) is to have a proposal.

Same thing for the javac defaults.


> -----Original Message-----
> From: Costin Manolache []
> Sent: Friday, November 08, 2002 1:30 PM
> To:
> Subject: Re: TaskContainer and nested data-types
> Stephane Bailliez wrote:
>> ----- Original Message -----
>> From: "Stefan Bodewig" <>
>> [...]
>>> Should data-types be allowed inside TaskContainer?
>> I cannot see any reason why they could not. Except enforcing data types
>> definition outside for style.
> +1.
>>> If so, UnknownElement needs to get fixed.
>> Houston, we have a problem.
>> Recent history shows that we cannot fix something that is possibly wrong
>> even though it is are plain incorrect/invalid/counterintituive. Which
>> means that if someone is shooting in his foot right now she must continue
>> and we must give them unlimited ammos to fulfill her action for the sake
>> of backward compatibility. Amen.
> I don't agree with this.
> History shows that backward compatibility is extremely important, and
> any change should take that into consideration. But we _can_ fix or
> change anything.
> A majority vote can decide what happens - make a proposal, add enough
> arguments - and if a majority of ant committers believe it's worth
> it - then it'll be done.
> Reminder: a code change can be vetoed, and if backward compatibility is
> broken I may be the first to veto ( unless I'm making the commit :-)
> But if a proposal for a change is voted and gets majority vote - and
> the commit just implements the group decision - I don't think a veto
> can be valid ( unless it provides a different/better implementation
> for what the community has decided ).
> In other words - if Stefan makes this change and committs - anyone can
> veto. If a proposal is made and a majority decides this is the best
> for ant - than a veto can only propose a better implementation for
> what was decided.
> If a majority of ant committers don't feel it's a good idea or worth
> the pain - then it shouldn't be done.
> Costin
>> I don't think that myself, and I think nothing is black nor white, what
>> is wrong should be fixed to avoid further problems in the future, you'd
>> better catch it now than 6 months later. But this is a typical example.
>> I know, I'm a PITA :)

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

View raw message