ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Diane Holt <>
Subject Re: Searching for build.xml
Date Sat, 04 Nov 2000 15:44:53 GMT
--- Ken Wood <> wrote:
> I've already said I worry about 'magic' behavior, but I do admit the
> find capability to be useful. Basically, I want it OFF in a production
> environment, but ON for developers.... so, with a flag, where it's off
> by default, and could be turned on at the command line or by the file
> that set's user defaults, I think we can have our cake and eat it too.

It's just never been clear to me why we need this particular cake at all.
The behaviour used to be:
   When nothing is specified, Ant looks for a build.xml file in the
   current directory. When found, it uses that file as a buildfile.
   To make Ant use another buildfile, use the commandline option
   -buildfile <file>, where <file> is the buildfile you want to use.
The nice thing about that, from my perspective, is that it's what I'd
expect. What I wouldn't expect (and why I "voted" against the change) is
for ant to wander up the tree looking for one, and executing whatever
happened to be in the first one it found. I'll tell you how I first got
bit by this change -- I was in a subdirectory, creating a "subproject"
build.xml file, and I 'vi'd bulid.xml (note the typo in the name), then I
said 'ant', to test out my new "build.xml" file, only, oops, it didn't run
the default target in the buildfile I'd just created -- it ran the default
target in some wholly other one, in some subdir somewhere up the tree,
doing things I didn't want done at all at that point. And that's when I
did two things: 1) I changed my wrapper-script to always 'cd' to the
top-level dir of the workspace tree, and 2) I changed the name of any
subdir buildfile to be anything other than build.xml (doing both things
may have been slightly excessive, but once bitten, twice shy).

At some point, after I settle on how I'm really going to have my project
and subprojects put together, and if the new behaviour is reverted, I
might go back to having my subproject buildfiles named "build.xml", and do
something a bit more elaborate for the wrapper-script, as far as where it
'cd's, based on the current working directory. Or maybe not -- haven't
really decided yet.

In any case, if you have a ("make-style") setup of a
buildfile-in-every-subdir, then the old behaviour works fine for that. If
you have a setup with a single top-level buildfile, then having the
wrapper-script 'cd' to the top-level workspace dir works fine for that. If
you have some other setup of project-and-subproject buildfiles, then you
can allow for that with other customizations to the ant wrapper -- which
is what you'd end up doing anyway, if the new behaviour was changed to be
determined by a command-line flag (eg., developers might have DEV=true set
in their env, and the script would pass the flag).

Just MHO,


Do You Yahoo!?
Thousands of Stores.  Millions of Products.  All in one Place.

View raw message