ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <>
Subject Re: [VOTE] Ant2 codebase adoption process
Date Fri, 25 Jan 2002 09:08:26 GMT
On Fri, 25 Jan 2002 04:21, wrote:
> On Thu, 24 Jan 2002, Peter Donald wrote:
> > Mainly because many of the features require backwards incompatible
> > changes which are unacceptable in a stable released project that is used
> > as widely as ant is. It would be iresponsible of ant-dev to put users
> > through this IMHO.
> Are you kiding ??? Ant internals have changed between each 1.x release - I
> can hardly recognize things.

Change is not the problem. Incompatible change is a problem.

> But my point was that no change or feature in ant2 justfiy braking
> backward compatibility at:
> - build.xml level
> - basic Task interface and patterns.
> If it can't provide backward compat - it's not worth it, regardless of
> what fancy features ( needed by 1% of the users ) it adds.

then the users will reject ant2 and ant1 will continue be developed.

> > With ant1.x there is a large effort not to break build files, this
> > sometimes is inevitable (ie every addition of a new task could
> > potentially cause conflicts) but we try to minimize the inconvenience.
> Could you explain this ? Except for adding a task that has the same name
> with a user-defined task, there's little else that can happen.

hmmmm - you think? When Connor added the ability for addConfiguredX to behave 
like addX except where component was "configured" prior to being added. This 
would break any task that had an element named <configuredX/> - unlikely to 
happen but possible. Any addition of a non-private method can also 
potentially cause conflicts because a lot of people subclass ant tasks and 
types. For instance when an extra method was added to the zip task it caused 
some tasks in AValon project to break because the avalon tasks used same 
attribute name. We also dropped support for certain XSLT Liasons because they 
were based on dropped unsupported products. So on and so forth.

These are things that we deem acceptable backwards incompatabilities because 
of the low risk of impacting users.

However there is plenty of things we would like to change or add but can't if 
we don't want to botch more than a handful of existing systems.

> Ant1 works very well - I haven't had almost any 'itch' with it in almost a
> year. If some functionality requires breaking build.xml and basic task
> patterns - I don't think adding it is the right thing to do.

thats been made abundently clear. There are however people asking for things 
all the time. You can see the same sorts of things being asked for over and 
over and over again. Most of these are symptoms of problems in initial design.

> Again - if ant2 can't provide backward compat at build.xml and Task
> patterns level, I'll not use it.

No one is forcing you to. If Ant2 sucks it wont be used and you can dance 
around its grave. 



 Don't take life too seriously -- 
                          you'll never get out of it alive.

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

View raw message