----- Original Message ----- From: "Joseph Dane" <[EMAIL PROTECTED]>
> > I don't think Ant should sacrifice backwards > > compatibility - in such cases, Ant Dev's approach > > Is compatibility really sacrificed here? Yes. > Sure, the change should be documented like any other change, > but can people really expect a new version of a tool like > ant to behave in exactly the same way as the previous version? A change to the existing behavior of <javac> practically means a rewrite of *every* ant build file out there. By making this change, we are forcing every build file to be rewritten to retain existing, and in most cases, accepted behavior, when an ant upgrade is made. > > > Wrongly assuming decisions like these have no negative > > costs, may impact existing buildomations in a variety of > > ways. > > Automatically retaining questionable decisions because of an > unwillingness to break compatibility reduces the overall effectiveness > of the tool. How is its effectiveness reduced? You can still configure it the way you want it to behave - just because you don't like the default doesn't make it any less effective. > But I should probably ask: why was the decision originally made to > make the default "no-debug"? http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1011 ...and related to this... http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5167 > joe Cheers, Magesh ************************************************** * The surest sign that intelligent life exists * * elsewhere in the universe is the fact that it * * has never tried to contact us. * ************************************************** -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
