Little history,
about 6 months ago I added build support to Alexandria. It seemed to
make sense that since I wanted to test build and Alexandria already had a
means getting hold of the source from cvs without to much hassle it seemed
good to just added in the ability to kick off a build.xml file is there was
one.
This mean where I work we have a hourly process that checks out all the code
and builds it (also runs JUnit tests) and produces a nice html page with
shows any build errors in red. This works pretty well, what it doesn't
provide is confirmation that any interproject dependencies are not being
broken buy code which is in development, this is important information for
some people but distracting for others who what information on how their
changes are affecting their code not how other peoples affect their code.
Enter Sam and Gump,
at the same time Sam was working on Gump which allows him to see
where dependencies between development version of projects. A good example
of how this is useful is the relationship between Alexandria and Castor
thanks to Gump Sam was able to identify a change in the behavior of Castor
which made is slightly stricter in the way it processed xsd files. This
meant one of the files in Alexandria was failing to build properly, because
we had warning of this prior to the release of the next version of Castor
Sam was able to fix the problem (Cheers for that Sam, I was a bit slow on
the uptake there). Brilliant we've caught and fixed a problem before it even
occurred.
Today,
I'm looking at how to integrate the sets of code Gump and Alexandria
part of this is making sure that both styles of build (checks against
release and dev code) are supported and it is easy to have both type running
at the same time. The other side of this is to look at the differing ways in
which the actual build is handled. Alexandria used to be based around bash,
but it became clear that Using Ant throughout the process was a better way
to handle things. I personally would like to see Gump go the same way, but I
don't want to through out the baby with the bath water so we're not just
going to abandon Gump as it stands at the moment.
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: 15 February 2001 20:07
To: [EMAIL PROTECTED]
Subject: Re: Nightly builds
Hi Sam,
I (think ) I got gump to work, it's not updating/building. There are few
issues/sugestions. I tried to find the alexandria list ( I assume the
discussion on gump happens on alexandria ), I'm sure it is somewhere and
I'll keep searching :-)
Anyway - it would be possible to switch tomcat3.x nightly builds to use
gump, with few small changes in the project definition.
The main issue is that (IMHO) you should relax a bit the
dependencies: a number of projects had releases, and I think other
projects should depend on the (stable) release of those projects.
For example, tomcat, servletapi, etc should depend on released-ant-1.2,
not jakarta-ant, etc.
Whenever a project has a major release - we should of course update the
scripts to make all projects depend on the latest "stable" and fix all
projects that are in development mode to match the latest "stable".
Given that each project has independent release cycle, I don't think it's
normal for a stable release of a project to depend on a development
release of another project ( for example, tomcat 3.3 shouldn't depend on
the dev. release of ant - but on the latest "stable" ant. If ant1.3 will
be released before 3.3 is "frozen", then tomcat3.3 should be fixed to
make sure it works with ant 1.3 - if not, it should stay dependent on
the released ant 1.2 ).
This can be resolved by adding "project/released-ant-12.xml", etc.
Another issue - wouldn't be better to generate build.xml instead of
build.sh and build.bat ? Most of the code inside build.sh can be done
easily in a "super" build.xml that calls ant. It is even possible to
use <java> tags to start different VMs.
I think this would be easier to maintain and enhance.
Another think - one planned feature for tc3.x build was a mechanism to
triger a build from a web page ( so if someone does a change, he doesn't
have to wait until the next night to find out if it brakes something ).
My plan was to use the <ant> taglib ( that is also used to run the tests
from a web page ) and write a simple build.war that will allow runs of
the build from the web.
That would also allow a lot of simplification ( since wars are
self contained and have a stable environment/structure ). It would also
modularize a bit the build ( a page to update a repository, a page to
build, no more "echo \<foo\>", etc )
Finally: it would be nice if the build scripts would get the sources using
<http-get> instead of <cvs>.
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
