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:20:17 GMT
----- Original Message -----
From: <>
> I never thought of checking in GCC and bash or gnumake with a project.
> I allways assumed the build tools as separated - I may use netbeans or
> eclipse which may have ant integrated.

You are not delivering a build to end users made with netbeans or eclipse.

You should add to source control the tool used to build so that you can
reproduce the build anytime even if your favorite build machine has been
satellized or vaporized, and when asked with what version of the compiler
you did it you should have an answer different than "mm.. I think it was
version x.y.z but I'm not sure if the latest patches were installed, I
remember installing some patches around august, does the date match with the
latest ?". If you upgrade your compiler in your build machine I'm curious to
know how you can reproduce a build n - 1 that was compiled with a previous
version of the compiler.

I have Ant installed on my computer but this is for thing done in local, for
quick throw away projects.

Ant is installed in source control as well as the JDK, with a script in each
place that makes reference to it so that I'm sure that every space cake
developper is actually using this one and I don't have a mix of v1.1, v1.2,
v1.3, v1.4, v nightly build to support. If I have to fix something I know
where to go, I know exactly what version of xalan, xerces and such are used,
rather than 'xalan 1 because I'm worth it', or 'yeah I installed Xalan
2.3D11 with Xerces 2.0beta3, help ! I have a problem with the <style> task,
I can't make the build to work !', sure dude, what else ? Who should I blame
when I have developper telling me that ? the developpers that do stupid
things or Xalan committers ?

Ant is critical to your build system.
bash, gnumake and other have small influence, I could probably add perl to
source control since there are some major differences and incompatibilities,
but this is not critical to the project build, it is all Ant based, perl
scripts are just helper scripts. I'm not adding cygwin to source control for
convenience because it takes about 200MB even though I should because there
are major incompatibilities (read bugs) between version and I'm forced to
send a mail to people to say 'upgrade or die'. I already have about 300MB of
third parties as well (xalan, xerces, cactus, tomcat, etc...with sources,
binaries and docs), another 35mb per jdk/os (removed src and docs). A
snapshot easily takes 1 GB. (this is where I wished all HTML docs could be
in a JavaHelp or CHM-like format automatically)

I would be a full time build engineer and not a 90% developper, I would do
it. I have already solved 99% of versioning that I have had in the past by
doing that. And it would not surprise you then to know that the Ant I have
in source control was upgraded from 1.4 to 1.4.1 only this week.

> I'm not sure I can get used with the idea of checking in the build tools
> as a workaround for their incompatiblities. It is indeed more and more a
> requirement for ant, and I'll have to do it ( it seems many projects have
> a ant.jar checked in ). But that _bad_, and as ant is integrated with IDEs
> it'll get worse.

I'm not able to run Ant's build file into IDEA unless I upgrade Ant behind
it. why ? because there are new tasks. I can actually even tell you that
Tomcat shipped with JBuilder 5 is actually not the one that most people use.
They just have to figure out what they do. If they don't this is not my
problem to put order in a configuration chaos where the developper does not
have a clue about what she has on her system. I try to do my best to
minimize chaos in my build, yet perfection is not possible but I try to
avoid most problems. Same you do in your code for bugs, you know you will do
bugs, you try to avoid code that may lead to bugs (because you consciouslly
know it) and do things to best way to minimize the workload later.

Build engineer is a full time job and I wish I had someone like Diane to
take care of that.


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

View raw message