ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Weighill-Smith <>
Subject Re: [RT] Define common project properties and tasks
Date Mon, 20 Dec 2004 09:29:24 GMT
> > It seems to me that there are as many completely different ways of
> > using Ant as there are projects in this world. If you were to supply a
> > "standard" build script, ready for customization, what input file
> > structure would it expect? What language would be compiled (if any)?
> > What distribution structure should be created and what files should be
> > used to populate it? What configuration control system should be
> > accessed to obtain the "input files" (if any)? What common properties
> > would exist? etc.
> Actually, I have not seen *that* many java project structures.

I assume from that comment you're limiting the "sample" builds to
simple, Java only projects? What properties and targets are you thinking
of being supplied?

> I mean, there is a source dir, a build dir, a tests dir...

We may do things differently to everyone else (though this is the second
time I've seen this type of project decomposition structure in a build)
but we have the concept of "subsystems" in our build as our source base
is fairly large...

Each subsystem has up to four source directories (hand-coded API and
implementation code plus the option for auto-generated API and
implementation code) and up to two test directories (unit and
integration test). Each subsystem also has a "build" directory that
contains two generated "source" class structures (API and implementation
separately) and two generated "test" class structures (unit and

Each subsystem has its own build.xml (which imports a standard set of
subsystem build targets that can be overridden or augmented as required
for the given subsystem, e.g. to generate code from an XML schema etc.).

There is then an over-all product build.xml (which imports a standard
set of product build targets that again can be overridden or augmented
as required, e.g. to create the JARs from the subsystem outputs).

Subsystems can depend on each other and on "external" resources such as
JARs etc., based on simple to use XML files that are used to
just-in-time generate Ant scripts that not only fetch the external
resources from a repository but also define the build and runtime

You could argue that we have a "standard" build (since we have standard
subsystem and product build imports) but I'm quite sure that a lot of
what we do is specific to our environment (e.g. how and why we interact
with our SCM - AccuRev - during the build process).

> > While I agree that there is some commonality across many Java 
> > projects (in that Java has a packaging mechanism that utilizes
> > directories etc. and that these projects commonly produce one or more
> > JAR files) it seems to me that this approach would either be too
> > restrictive on the type of project that could utilize it or that so
> > much customization would be required as to negate the usefulness of
> > it.
> Netbeans thinks otherwise, and in fact *does* include a basic build.
> All IDEs have their layout, and tons of projects have used it without 
> customizations.

One wonders just how scalable this basic build is (having not seen it I
can't pass any further comment).

> > Perhaps better to provide some more sophisticated example build 
> > scripts covering the use of Ant on client side and server (multi-JAR)
> >  Java projects (and other languages if any contributions could be
> > taken for these). I'd especially like to see examples that:
> > 
> > * split the build into several sections (perhaps using subant) in 
> > order to generate multiple, "tree dependent" JARs (i.e. one JAR
> > depends on another but there are no cyclic dependencies) 
>  >
> > * utilize
> > something like XSLT to generate Ant scripts from simple XML files
> > that define the inter-dependencies within such a multi-part build 
>  >
>  > * use a repository accessor (along the lines of the "get libraries"
> > stuff that has recently been discussed a lot on this list) to obtain 
> > dependency JARs from other projects
> Krysalis Centipede did this years ago, but the project failed.

Shame. Possibly because its of most use to large developments like ours
which are perhaps fewer and further between?

Phil :n.

Phil Weighill-Smith <>
Volantis Systems

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message