ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephane Bailliez" <>
Subject Re: Speaking of deprecation...
Date Sun, 10 Feb 2002 11:55:41 GMT
----- Original Message -----
From: "Sam Ruby" <>

> Just curious, do you also do this for the perhaps most basic of build
> of them all: javac?

I have answered this question about our shop.

> Or are you like most of us and when you install a new patch level of the
> JDK you pretty much do it globally across all the projects that you deal
> with?

There are some nasty bugs fixed between JDK versions, I want all to benefit
immediately without being called to the rescue because the version 1.3.0.b24
compiler crashes with a NPE sometimes when doing some kind of incremental
compilation with Ant and that this particular one has been fixed in 1.3.1.x

> I find the line is different for everyone, but over the past few years I
> have noticed a trend whereby most people outside the immediate ant-dev
> community are treating ant as more javac like.

I don't know what you mean here, but to me you are forced to put Ant into
source control because of all dependencies.

A shop may have custom tasks developped and/or may be running with a
specific set of third parties (being xalan, xerces, junit, etc...) once you
want to upgrade or you 'know' your buildfile works with Ant v1.4 and all
versions of binaries there, anyone can come and 'build', whatever the
version in local (oh, you don't have oro in your path, probably have
a buggy version of Xalan, I think this bug was fixed in xerces 1.4.3, I had
1.4.4 when running it and you have 1.4.1, that should explain, oh this
method does not exist anymore in JUnit 3.7, etc...).

It simply does not work when there are so many things to upgrade while this
can be done smoothly when using source control. The line is of course
different here at Jakarta mainly also for license problems I believe.

Gump runs using  'HEAD' being on the thirdparties and projects. If I want to
build using a particular build label and that's it.
I'm able to redo the exact same build with the same JDK and same binaries 12
months later once it has been shipped and set in maintenance branch while I
have another JDK version and binaries in the development branch.


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

View raw message