You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@xml.apache.org by Stefano Mazzocchi <st...@apache.org> on 2000/08/07 20:59:55 UTC
Nighly builds
[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.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
Re: Nighly builds + MacOS9
Posted by Robert Burrell Donkin <Ro...@appleonline.net>.
Yes i know that this is a little (well ok - more than a little) late but
with all the traffic it's hard to keep up. it's interesting what you said
about scripts because it's actually impossible to start a java application
on a mac with a script - it has to be wrapped in a mac os application to
get it started. i'm not sure wheither what i'm going to say will be true
about MacOSX (i could find out but until the public beta comes out any info
couldn't be made public in any case) but it's certainly true of MacOS9.
There has been lots of talk about various apache java projects...
(or should that be projects from apache.org written in java, not
neccessarily but possibly including apache-java ;-) )
...and the difficulties of running them on this platform on apple lists.
There seem to be plenty of people interested but the effort invoved in
getting stuff like tomcat to run is great.
In particular, the problem is that you have to create an application to
run it. This isn't too hard but probably enough to put off quite a few
people. You have to go through the trouble of getting apple's SDK etc and
reading documentation and so on. but - in my view - the real problem
involved with running on MacOS is that it's almost impossible to know
what's gone wrong. What happens a lot is that the stdout window lasts only
as long as the application and if the application dies too quickly you
can't read anything. There is a trick which i used to get round it - you
simply write a starter class with error handling code and a frame with
start and stop buttons ( or whatever the scripts do) which mimic the
actions of the scripts but use direct calls to the java classes.
(Incidently i know why most people can't get tomcat to run on macos and
it's their TCP/IP settings.)
I suppose that i should cut to the chase about now. For MacOS it's a
chiken-and-egg situation. You'll need a MacOS wrapper application to run
whatever java application you want to run - wheither it be Ant or whatever
- but it might be possible to produce a single MacOS wrapper/builder which
wraps Ant and adds just a few more classes so that it can be run, and then
in addition to the other stuff produces a 'standard' application wrapper
for the built application. This would make issueing MacOS versions do-able
since they could be done by the people downloading and compiling with Ant -
and i know that there is demand out there for this type of stuff.
hope this isn't too left field, robert
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.
> <st...@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
Re: Nighly builds
Posted by Arundhati Bhowmick <ar...@hyperreal.org>.
I'd back Mike for getting nightly builds for C++ too. It's true that we would
have different settings or batch files to execute C++ and Java but both builds
could be posted to Apache server through the same login id.
In this regard I'd propose having a login id on the Apache server (for xerces
builds) which could be write permit to xerces-c and xerces-j directories only
for C++ and Java respectively. There would be no need for cvs commit acces for
this login. So its a minima access id which can be given to the person willing
to take resposibilities for posting the nightly builds.
I'm requesting this as we already have most of the process set for xerces-c
nightly builds at our end but due to the lack of this id the posting cannot be
done by the automated process.
Arundhati
Sam Ruby wrote:
> Mike Pogue wrote:
> >
> > 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!
>
> While I would like to see that too, it is a matter of trying not to bite off
> more than one can chew. I also believe that the classpath issues associated
> with Java are unique and need a special focus.
>
> At the moment, there is a demonstrable problem with the Java projects in
> that it seems rare that you can pick two Java projects and have them work
> together out of the box. Typically, there is a mismatch in some dependency
> or another. This problem is exacerbated by each project shipping their
> dependencies.
>
> P.S. One of the most common complains it some method missing in
> org.w3c.node, and no class in the classpath (based solely on its name) is
> obviously associated with w3c...
>
> ---------------------------------------------------------------------
> 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
--
Arundhati Bhowmick
IBM -- XML Technology Group (Silicon Valley)
Re: Nighly builds
Posted by Sam Ruby <ru...@nc.rr.com>.
Mike Pogue wrote:
>
> 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!
While I would like to see that too, it is a matter of trying not to bite off
more than one can chew. I also believe that the classpath issues associated
with Java are unique and need a special focus.
At the moment, there is a demonstrable problem with the Java projects in
that it seems rare that you can pick two Java projects and have them work
together out of the box. Typically, there is a mismatch in some dependency
or another. This problem is exacerbated by each project shipping their
dependencies.
P.S. One of the most common complains it some method missing in
org.w3c.node, and no class in the classpath (based solely on its name) is
obviously associated with w3c...
Re: Nighly builds
Posted by Mike Pogue <mp...@apache.org>.
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.
> <st...@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