xml-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Pogue <mpo...@apache.org>
Subject Re: Nighly builds
Date Thu, 10 Aug 2000 00:01:20 GMT
I'd like to see a solution that works for our C++ projects, too.
I don't think we want to require Java for those!

I think we're just about there with ANT for Xerces-J, but I think we should be
thinking of more than just Java for our solutions....

Mike

Stefano Mazzocchi wrote:
> 
> [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
> interoperability.
> 
> 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"
> value="${build.dir}/printer-docs"/>
>     <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
> scripts.
> 
> 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 ---------------------
> 
> ---------------------------------------------------------------------
> In case of troubles, e-mail:     webmaster@xml.apache.org
> To unsubscribe, e-mail:          general-unsubscribe@xml.apache.org
> For additional commands, e-mail: general-help@xml.apache.org

Mime
View raw message