cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Turner <>
Subject Re: Standardizing build.xml files
Date Fri, 07 Sep 2001 04:40:42 GMT
On Thu, Sep 06, 2001 at 10:26:34PM -0400, Berin Loritsch wrote:
> I proposed this on the general lists, and got a couple +1s
> from the folks there.  Please let me know if this makes sense
> for us.  This proposal is a minimum set of targets and
> conventions for build.xml files.  This allows a familiar
> environment for all projects (if adopted).
> If a program can be installed, then a build file must
> use these properties (which can be overridden by a user's
> .antrc file).

.antrc is for setting environment variables. It is distinct from (aka, which I presume you mean?

> The properties and default values follow:
> * install.dir=.
> * install.bin.dir=${install.dir}/bin
> * install.lib.dir=${install.dir}/lib
> *${install.dir}/conf
> * install.doc.dir=${install.dir}/docs
> By using these properties, Ant is able to customize how the
> program is installed and filter the scripts to point to the
> proper jars, etc.

Good stuff. I've found that often, the source directories are made
painfully explicit in properties, but the destination is simple "dist"
or "build", with no further granularity of where individual parts of the
distribution go.

> The standard targets I propose we all adopt are similar to
> the Make utility conventions ('all' is the default target):
> 'all'
>     Compiles the program with debugging enabled by default.
>     This target is not required to build documentation.  Standard
>     compilation properties and defaults are:
>     * build.debug=on
>     * build.optimize=off

Great. I've noticed a tendency for people to call this "main". Anyway,
it's a good addition, because it allows "ant clean all" to be done on
any project, whereas without knowing the default target, you're stuck
with "ant clean ; ant".

> 'install'
>     This target ensures that everything is built, including
>     documentation.  It then copies the files in the corresponding
>     directories already mentioned above.  All jars should be
>     considered libraries, and scripts should be provided to run
>     them.

A bit off-topic but..

I've managed to avoid "invoking scripts" in my projects by adding the
following to the jar manifest:

Class-Path: [requisite jars]
Main-Class: [main class]

Class-Path: crimson.jar jaxp.jar catalog.jar
Main-Class: net.socialchange.validator.Validator

Then the project can be invoked with "java -jar foo.jar".

> If installation is not provided by a project,  the
>     build script should display a message to that effect.  Optionally,
>     {build.optimize} could be set to "on" for this target.
> 'uninstall'
>     This target removes all the project files from the afformentioned
>     directories.  IMPORTANT:  The uninstall script should NOT
>     assume that the {install.[*].dir} directories are direct decendants
>     of the {install.dir} directory.

Very well noted :)

>     If installation is not provided
>     by the project, the build script should display a message to
>     that effect.
> 'clean'
>     This target deletes all files that are generated by the build
>     process--but does not delete files used to configure the build
>     process.
> 'distclean'
>     This deletes all files that are left from clean and returns the
>     project to its distributed state.
> 'docs'
>     This generates all documentation for a project.  This includes
>     user docs and javadocs.
> 'javadocs'
>     This simply generates the javadocs for the project.
> 'printerdocs'
>     This generates a printer friendly version of the documentation.
>     Most projects dynamically build their documentation from XML
>     anyway. They should provide a nice and simple stylesheet that
>     avoids all the HTML tables embedded in tables approach most
>     site docs use.
> 'dist'
>     This target should be used for generating all the artifacts used
>     for a distribution.  That means the tar ball and zip file used to
>     distribute projects, and any dynamically generated announcement
>     files.
> 'check'
>     This target is used to compile and execute any unit tests that
>     are built into the project.

Or just "test"? 

Another question: what is the default target? I don't see anything
suitable above, because they all build docs, which usually takes a long

I'd suggest keeping a "main" target, defaulted to "all", which people
can then change to "all, tests" or "clean, all, tests" as they see fit.

(wishing you success where others have failed)

To unsubscribe, e-mail:
For additional commands, email:

View raw message