New machine:
I've gotten access to nagoya.apache.org. It is billed as a fast machine
from Sun. So far, I've not seen the speed. Gump runs that take 3 to 4
hours on Pentium III's seem to take 6 on Nagoya.
Proposed option: parallel copy operations:
One way to address the speed issue is to do the cleanup and copying of
build directories in parallel with the checkouts. In particular, the
order can be:
rm -rf A &; update cvs/A; wait; cp -r cvs/A A &; rm -rf B &; update cvs/B; wait;
cp -r cvs/B B &; ...
This change could bring Nagoya back to parity with a Pentium.
Catastrophic dependency failure insurance:
Suggestion from Geir Magnusson Jr: if at the completion of every
successful build, the output jars are copied to a well defined location
and then this location is used as the source for resolving dependencies,
then we have a system that automatically upgrades. I kinda like this
idea, and am curious what other people think...
This discussion was motivated by yesterday's xml-xerces build failure...
Defining a few terms:
I think of gump as a PROFILE. A set of PROJECTs and TAGs that at least
one person sees as an interesting configuration. The proposal
directory, contains a codebase which while fun to write and useful at
the moment, I view as totally expendable. Hopefully other people will
someday define other profiles of interesting configurations.
I see a WORKSPACE as corresponding to a physical set of files on your
hard drive. Hopefully in the future, the definition of a workspace can
be produced by combining and subsetting profiles, as well as adding in
additional projects.
I see a build TARGET as something you reference to specify what you want
built. At the moment, only projects and a special target named "all"
are defined, but it would be nice if you could define your own subsets
Repositories:
I've begun work defining the repository in a manner more consistent with
the way Alexandria does it and yet definine the elements that make up a
cvs root in a more fine grained manner. This will allow sourceforge and
exolab to be considered as a single repository even though there are
changes to the actual cvs root required when going from one module to
another.
Future plans:
Once I get the DTDs for Gump closer to Alexandria's, I still plan on
spliting this profile out to a separate CVS module with a considerably
larger base of committers. I do plan to get back to the Python
implementation, I'm also planning on adding in the various exolab J2EE
projects - hence the motivation for enhancing the way that repositories
are defined.
- Sam Ruby
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
