ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <>
Subject Re: Default setting of the javac includeAntRuntime attribute?
Date Mon, 05 Jan 2004 13:04:10 GMT
Kenneth Olving wrote:
>>There are lots of things that are inconsistent & due to backwards 
>>compatibility. No, we dont want to change them.
> Fair enough, I can relate to that. And as Mr Fernandez points out, there may be a better
solution anyway in this particular case.
>>do you want to field 
>>every bug report that comes in saying we broke their build?
> Touchy, aren't we?

No, though I am a bit grumpy with telcos this morning; the subject of 
DSL provisioning is a sensititive one today.

asking if you wanted to field the calls was a serious question -any 
change to the runtime's semantics will result in many bugreps, and 
someone will have to deal with theim.

> No, not particularly. Sometimes though, some things may hurt enough that backward compatibility
is sacrificed, which I just wanted to hear some opinions on, with, I hope, a courteous and
simple query. I'm sorry if I offended you.

I'm not offended; its quite often that people want to fix the 
inconsistencies. The problem is that we are fairly confined by what we 

The worst changes are those that make it impossible to write a build 
file that works consistent on both versions of ant, yet appears to work 
on both versions. Adding a new task or type clearly wont run on an old 
version, but changing a default is the kind of subtle change that 
doesn't appear to break things, but changes the expected results. People 
really hate it when we do that.

includeAntRuntime is clearly one of those legacy hacks. Originally the 
ant runtime was always included; the addition of a switch to turn it off 
was the new keep the old builds working the switch was off 
by default. Similarly, the <exec> and <java> tasks have 
failonerror=false as default, nearly everything else has it set to true, 
because those two tasks predate the failonerror pattern.

Eventually backwards compatibility will box us into a state where it 
becomes impossible to make progress or write good build files. This is 
why so much discussion goes into the merits of new features (like 
namespaces), because if we get it wrong then it will make everything 
wrong down the line. If there was too much focus on the immediate 
solution we'd end up with something like Win32 API, rather than 
something more consistent (like the Unix API).

> Thank you anyway,
> ken1
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message