ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Backward compat ( was: Re: Ant 2 et al.)
Date Wed, 10 Jul 2002 16:34:14 GMT
On Wed, 10 Jul 2002, Conor MacNeill wrote:

> > Is there any project in jakarta, built by gump, that uses this construct ?
> > It seems most agree that 'build all that gump does' is acceptable
> > backward compat.

> Wow - is that your definition of backward compatability? 

> It seems people talk up backward compatability until it gets in their way.

It seems that's what ant-dev considers acceptable. 

My definition is a bit different - I'm strongly against 'cosmetic' 
changes, and most API changes ( there are enough ways to preserve
the old APIs - by using new methods and aliases, up to facades ). 
If a change has clear benefits for most users - and the pain
is reasonable ( and can't be easily avoided ) - I'm +1.

You make me look like a fanatical who won't accept any change. I think
my position is entirely reasonable, and few other people are using
'backward compatibility' argument in unreasonable ways.

I do talk about backward compatibility when I see trivial cosmetic
changes ( like jarfile/destfile ). Or when methods are removed/renamed
even if it is trivial to preserve the old signature. Or when people
talk about renaming <project> to <build>, just because it is 'cleaner'.
Or when the Connection interface gets few more methods making it 
impossible to write drivers that work with JDK1.3 and 1.4 ( instead
of just adding a separate interface ).

This is totally different from breaking some build.xml files 
that are invalid under the current XML spec - with the benefit
of adding namespace support and solving the naming issue and 
possibly making the whole thing easier to use. 

I hear the claim that 'it is ok for ant2 to break compat, but 
nothing can change in ant1'. Well, compare ant1.0 with ant1.5 -
it seems all 1.x releases except the last had incompatible
changes and would fail the gump test. I'm pretty sure even
with 1.5 we can find some extreme cases where things will
brake - but overall I think the users will benefit greatly
from the 'backward compat' arguments. And it was well worth 
the flames. 

The reasons I'm against both ant2 proposals is not 
backward compat - but the design, which I find worse
than ant1. I did look at the code - and it screams 
"over-engineering" and "featurism". 

For most task developers there are 2 classes that matter -
Project and Task. The XML APIs consist of 3-4 classes. It
is possible to embed ant using 2-3 classes ( and if a cleaner
API is needed, that can be done without major problems). Compare
this with the forest of interfaces and classes in the proposals.
If you want a framework - use one, don't turn ant into one. 

Do we need a clean ComponentManager interface - yes. But it 
can be easily added to ant1.6 - with Project methods calling
it ( and 100% backward compat ). Do we need a Task interface? 
I don't think so, java beans are enough. I think we 
need to extract some of the things in Task, Project into 
separate services ( commons-like ) that can be used by 
tasks without having to extend Task and independently of
ant. But all that can be done in ant1.6, ant1.7, etc - 
with reasonable backward compatibility. Of course - all this
is MHO, and each step should be discussed until we're all
comfortable with a solution. As oposed to get a package
of pre (or over ) cooked solutions as a new codebase.

> > If it is indeed something usefull, and we agree on that - is there 
> > anything to prevent adding it to ant1 ?
> backward compatability :-)

I see. Using the definition that backward compatibility is broken
by adding any usefull features to ant1 that would make mutant
less usefull. 


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

View raw message