xml-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Nighly builds
Date Mon, 07 Aug 2000 18:59:55 GMT
[Sam, are you subscribed to general@xml.apache.org?]

Sam and I once discussed the creation of "good" nighly build
infrastructure for all apache projects written in Java and need

There are some problems that need to be addressed:

 - some projects still use make instead of Ant. This makes it hard to
create a common infrastructure. Both Sam and I volunteer to help
projects remove makefiles and jump on the Ant bandwagon entirely. As for
early problems of the 
Xerces team (and from their TODO), yes, Ant is able to leave out files
from the build if you want that to happen.

 - all projects that use Ant have a build.sh/build.bat script that
starts Ant and sets the classpath required to perform the compilation. I
came to consider this harmful since it forces the project to contain the
required binary jar files inside their CVS module.

 - classpath themselves are considered harmful: Java uses classpath as
the default method to find classes, but this is not the only method.

I'd like to investigate the creation of a special Ant classloader that
is able to cope with these problems without requiring scripts to fill
the classloader.

This is better than scripts for many reasons:

1) Being Java it's totally portable (so we avoid managing three scripts,
one for UNIX, one for win32 and one for MacOS)

2) It may add specific versioning semantics like "I require Xerces 1.1.2
or later"

3) It may be able to automatically "downgrade" the version of the
required package until the build goes thru.

Besides Ant-usage coherence and system-abstracted class loading, the
only missing thing is build-file coherence that should allow the build
locations to be redirectable.

For example, from cocoon2 build file we have

    <property name="build.root"     value="./build"/>
    <property name="build.dir"      value="${build.root}/${name}"/>
    <property name="build.src"      value="${build.dir}/src"/>
    <property name="build.dest"     value="${build.dir}/classes"/>
    <property name="build.docs"     value="${build.dir}/docs"/>
    <property name="build.docs.printer"
    <property name="build.war"      value="${build.dir}/webapp"/>
    <property name="build.javadocs" value="${build.dir}/javadocs"/> 

which allows us to call

./build.sh -Dbuild.root="../build"

to follow jakarta-style building process (which uses a common build
directory for everything.

On the contrary, the same things taken from FOP doesn't allow that

    <property name="build.dir" value="./build"/>
    <property name="build.src" value="./build/src"/>
    <property name="build.codegen" value="./build/src/codegen"/>
    <property name="build.dest" value="./build/classes"/>
    <property name="build.docs" value="./build/docs"/>
    <property name="build.javadocs" value="./build/javadocs"/>
    <property name="build.tests" value="./build/tests"/>

since all directories must be changed (this is clearly a design fault,
but not easy to grasp).

The nightly build should be implemented as another build file that calls
the other build files with the <ant> task.

Moreover, given the ant nightly build log file in XML, we can
xslt-stylize it and publish it on the web directly... we should aim to a
tinkerbox-like system but without requiring the use of unportable

What do you think?

(of course, I want to place the jakarta folks in this as well, but we
need to agree on something at the Apache XmL level before going on, so
place your comments soon).

Again, do not worry: we'll provide any required help to get Ant up to
speed in your projects but we must follow common guidelines and have a
certain building coherence among different projects, expecially those
that depend on one another.

Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------

View raw message