Splitting Ant files - extrapolating into smaller ones? Is there a clean way or bestpractice?

Question

I'm re-working an ant build file that we've been using on our project for a long time. It's starting to get large and unwieldy with lots of targets and properties. I want to extrapolate and break it down into smaller files.

Since I'm fairly new to ant, I'm wondering

what's the most commonly used way of splitting build.xml files into smaller pieces?

I'd like to do it in the most clean, easy to follow method possible, keeping only related targets/properties in each file.

So, for instance, all targets/properties related to compiling will go in one file, all related to logging will go an another and all related to deploying will go in a third. Thereby, the build.xml file will get cut into 3, smaller files that are much easier to chew on.

Answer 1

Why would you bother to do this?

Breaking the file into smaller pieces makes sense if you are trying to share a common set of logic across multiple projects (but only want to share certain parts) but breaking up a large build.xml simply to have smaller pieces doesn't seem worthwhile to me.

Answer 2

Carej, My main reason is to make it easier to read, understand and maintain similar to the way sections of code in a very long method can be extrapolated away into sub methods. As in:

public void vend() {
    /* 10 lines of code about accepting money */
    /* 10 lines of code about calculating change */
    /* 10 lines of code about vending soda */
}

Becomes

public void vend() {
  acceptMoney();
  calculateChange();
  vendSoda();
}

With each of the sub methods having the chunks of code as in:

public void acceptMoney() {
    /* 10 lines of code about accepting money */
}

Another reason is because of exactly what you mention, if I am able to elegantly break it into smaller parts, those parts have a chance of being reused and subsequent build files become easier to create. Just modify the value of a few properties, and I can use some sections in may different applications.

It would just make sense that there is an accepted way to pull targets and properties into separate files all used by one build file. Does anyone know of such a way?

Answer 3

Use Ant macros to abstract common processes like compiling, building archives, etc. This allows you to have a fairly concise, readable main build script with lots of one-or-two-line macro calls and another file with reusable, general purpose procedures. This kind of abstraction is easier to achieve if you have used consistent naming/directory conventions throughout the project.

Answer 4

A combination of Ant macros and antlibs will not only reduce your build scripts but also hide away all the complexity.

For an example, you can take a look at my pet project. The Antlib files are packed inside a jar file, placed in the Ant's lib directory.