Re: Nighly builds + MacOS9

[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