here follow isome rules that my project tries to stick to. this is nothing
standard so do watever u want w/ it,
++.
seb.
INTRODUCTION
=============================================================================
The builddefs.xml file provides common definitions for ant files. The
goal is that components that adhere to a common set of guidelines can
create very short build.xml files. At the same time, components should
be able to deviate from the normal build processes by modifying definition
only where the component needs to deviate.
VARIABLES LOCATIONS
=============================================================================
The builddefs.xml file makes heavy (and ocasionally creative) use of
variables. Many are defined in the builddefs.xml file itself, but there
are allowances for user and project customization.
A build.properties file will be read from the user's home directory and
from the project's build/build.properties file. Definitions here take
precedence over other definitions found in the builddefs.xml file.
In addition, vendor software is located using a project specific file
named vendor.properties (definitions here are lower precedence than
the previous build.properties files).
VARIABLE NAMING
=============================================================================
Variable names start with the name of the target that uses them as
much as possible. For example, class files are written to a classes
directory. Since the "compile" target (more on targets below) uses
this definition, the variable pointing to the directory is named
compile.classes.dir.
NOTE: There is some duplication here. The jar target, for example,
also needs to know the location of this directory. For the jar
target, the name is "jar.base.dir" If this changes, the names should
be based on the first target to need the definition.
On ocasion, a target has related targets. An example is the code-gen
target. There are related targets such as code-gen.xdoclet. Variable
names specific to this target should be prefixed with code-gen.xdoclet.
NOTE: I know that this will lead to some long variable names. Since
they are only in one file, fine.
Variables storing target names should be prefixed with "target."
THE TARGETS
=============================================================================
The builddefs.xml file centers around a small set of targets providing
a high level view of the process. These high level targets call other
targets to do the real work.
For example, the "compile" target does not really do anything other
than call the target name stored in the variable "target.compile" which
by default is contains "default.target.compile"
The definition of the "compile" target follows:
<target name="compile" depends="code-gen"
description="Compile Java source files to class files.">
<property name="target.compile" value="default.target.compile"/>
<antcall target="${target.compile}" inheritrefs="true"/>
</target>
Note that the "target.compile" variable is provided a definition
in the "compile" target itself. This makes use of the fact that
ant will not re-define a property. If a component needs to do
something extra in the compile step, it can do something like
the following:
<target name="my-compile" depends="default.target.compile">
...
</target>
<property name="target.compile" value="my-compile"/>
This will cause the "compile" target call "my-compile" which
depends on "default.target.compile" thus doign both (the default
first). If you only need a custom definition, then "my-compile"
need not depend on "default.target.compile."
VARIABLES USED BY TARGETS
=============================================================================
Targets should make every effort to allow a component to over-ride
definitions needed by the target. This is done by creating the
final definition prefixed by "default" and creating a property that
contains the default definition name.
