Best location for ant build.xml files?

Question

For those of you that use Ant with multiple projects, where do you put the build.xml files? Do you put one in each project, or do you put them in a separate project that contains all your Ant-related files?

The usual recommendation is to put a build.xml in each project. But this has a few drawbacks:

• It makes it hard to reuse common targets in multiple projects.

• Sometimes you want to use Ant to export a project from source control and deploy it. Obviously you can't do this if the build file is in the project itself.

But if you put them all in a common location:

• People need to be aware of their location to use them; they can't just use "ant -find" to find the current project's file.

• You can't have different build instructions for different branches of the project.

What do you guys do?

EDIT: Thanks for the good suggestions so far. As far Maven, these aren't Java projects, and I get the impression that Maven is only meant for Java.

Answer 1

My rule of thumb is to put the build.xml file in the directory under which all files are referenced. In other words, no relative paths should start with "../". Where I live, that usually means putting it in the "trunk" directory, which has src, lib, build, docs, etc underneath it.

Doing this makes the paths much cleaner in the file, and it makes it obvious how to build the project.

Where I have multiple projects that need to build, I will create a separate build.xml for each project, and a central build.xml in the directory all the project are in that calls those other build.xml files. That gives you a lot of flexibility with very little work.

Answer 2

I'd expect an Ant build file to be located at the top of a project (it's already a pain to have to look at a the build file to "discover" how to build the project, so if I have to locate it first, it'll drive me totally crazy). Now, regarding all the drawbacks you mentioned, I'm tempted to say: why don't you use Maven?

Answer 3

Place the Ant files with the project. That is the de facto standard and recommended by the creator of Ant. I will try to address some of the issues you have brought up:

• Reuse of common targets should be done using techniques as described by Eric Hatcher in his book Java Development with Ant. Basically, you extract all commonality into a some top level files that all other Ant files "inherit" from.

• Using Ant to export a project from source control seems odd to me, but if you want to do this, use a different Ant file :-) You can make a target like ant export -Dproject=foo/bar.

For Ant, I recommend you grab that book - it has a ton of helpful techniques.

The real recommendation I would make though is to drop Ant and convert over to Maven - like the Apache Software Foundation did (they maintain both Ant and Maven).

Answer 4

The way I have done this is in the past (Now I just use Maven):

• Have a build.xml in the root of each project
• Create an overarching build.xml for all projects and place it in the trunk of my repository
• The overarching buid.xml has checkout tasks for each project. I am guessing when you mentioned export from repository, you actually meant import.
• The overarching build file also defines the dependencies, if any
• You may update individual projects using each project's individual build file
• If you do have common tasks defined, you may inherit from a common build file as well as someone else suggested.

Looks like your set of projects might be a good candidate for migration to Maven, I realize it is not always possible but if you have time, you might want to look into it.

Answer 5

If you're working with independent projects, you can:

• put your build.xml at the top level
• place common Ant definitions (Antlib) into another project (e.g. config)
• use svn:externals to import the common Antlib definition (from 'config') into your project

EDIT The trick with svn:externals is that if you link to the HEAD of some common files, it may happen that they will change after a couple of months/years. So each time you tag, you should change the svn:externals to point to a fix version of the included project. This may come handy when a project has to be rebuild years after it was last built.