"include" capability?

[Bear Bibeault]

One thing I haven't seen anywhere in the ant documentation or examples is an easy way to share common "snippets" between build scripts.
I have ant build scripts for 17 projects (my answer to the question 'when should I use ant to automate building my project?' is 'always!') and have multiple taskdefs which are repeated in each build script.
It'd be great to have the build scripts 'include' or import the taskdefs from a single source.
I make copious use of shared property files, but that's obviously not going to help out here.
thanks,
bear

[Kirk Pepperdine]

There are a couple of stratigies that you might consider. First, you can call one ant script from another using the ANT task. The other is, the build files are written in XML and consequently are subject to XML rules. So, you can use a standard XML include.
In terms of preference, I prefer the former though I could see an argument for the later.

[Jay Damon]

I have been able to get includes to work by placing a statement similar to the following in the build script:
<!DOCTYPE project PUBLIC "-//ANT//DTD project//EN" "dtd/project.dtd" [
<!ENTITY include SYSTEM "include/common.xml">
]>
I don’t understand why it is so complicated; all I know is that it works. Perhaps our guest moderators can expound as to what all of this is and why it is required for such a simple task.

[Frank Carver]

There is also another option. You might think of your ant build scripts as "compiled code" and build them by assembling "chunks" using weatever technology takes your fancy. I tried this for a while, but I was using XSLT to generate the build files and had problems with some significant characters. If I were to consider this approach again, I'd probably use an XML-neutral template approach such as WebMacro, Velocity etc., or maybe some of the additional ant tasks for manipulating XML documents.
Currently I use the approach of just calling out to common ant build files. It would be nice if the syntax were a little cleaner, but it's easy enough to do:

 
  <target name="build" depends="test,jar">
    <ant antfile="${scripts}/build-war.xml" inheritAll="true"/>
  </target>

in my application, and have a build file in the "scripts" directory like:

<project default="build-war">
  <property name="source.root" value="build"/>
  <property name="dest.dir" value="."/>
  <property name="deploy.name" value="app"/>
  
  <target name="build-war">
    <jar jarfile="${dest.dir}/${deploy.name}.war">
      <fileset dir="${source.root}/delivery/files"/>
    </jar>
  </target>
</project>

The non-obvious trick about this is that Ant's "immutable" properties can be used as parameters. If a property is already set before another build script is called, the supplied value is used instead of the default value in the called script. I could instead call my "build-war" script as:

 
  <target name="build" depends="test,jar">
    <ant antfile="${scripts}/build-war.xml" inheritAll="true">
      <property name="source.root" value="src"/>
    </ant>
  </target>

to override the "source.root" property.
I find this provides a fine level of script re-usability.

[Kirk Pepperdine]

Frank,
Thanks for providing the long answer to my terse "nested build script" answer.
I find the thought of using XSLT both intreging and frighting at the same time....
As for why all of the XML mubo-jumbo just to get a file included??? Well that syntax was setout by the xml consortium, I defer the answer to them as I can never remember it, I always end up avoiding or using a cut & paste

[Frank Carver]

I tried the "XML mumbo jumbo" approach for a while, too, buf found in the end that it is not as flexible as using the "ant" task to call other scripts. There is no easy equivalent to the trick of specifying default properties and allowing them to be overridden.
I seem to recall reading somewhere that the next version (1.6?) of Ant will probably include some sort of more explicit (and less "mumbo jumbo") "include" mechanism.