[EMAIL PROTECTED] wrote:
gen.sh = bootstrap
I'm just frustrated. Don't let it get to you. I try not to :-) I'm also trying to update docs/code as I find things that are hard to understand and use.
For example, the web site says to use gump, you run gen, update and build. But what's not clear is when you would want to re-run them, and what they produce. e.g. Why would I want to re-run gen? What's the relationship with the gen target in build.xml? etc....
gen target in build.xml is what you "normally" use after you have successfully bootstrapped.
Getting started:
gen.sh
update all
build all
At this point, you can
1) directly make a change to any project and build it with
build project target
if you then want to build any other project, you can simply build
that project, and you will automatically pick up your fixes to the
first project.
2) run cvs update against any project and build it, just like above.
This is very useful for isolating integration breakages. Recently
there was a build breakage that was caused by a change to ant. I
never understand the cause and effect relationship between the change
and the breakage, but I was able to "cvs -q update -D date" the
version of ant to the point in time just before the commit in
question and build both ant and the other project. Doing a cvs
update which included the additional one file change and rebuilding
ant and the the other project reproduced the failure.
3) rm -rf a project and rebuild it. The build script checks for the
directory being there, and if not found, will automatically copy the
source from the latest update. This is helpful when you make some
changes and realize that you are making things worse... ;-)
I've been doing this for two years now, and plan to continue for the foreseeable future. I don't know you well enough yet to know based on your email as to whether this was merely irritating or actually infuriating. It appears to have been the former... good.Frustration often gets fixed....
Does this mean projects like James who have had failing gump builds because of changes in dependencies, can specify a version of a gump built jar to use until the problem is resolved?I don't particularly want to get into the combinatorics of every project depending on particular nightly snapshots of one another, but will support for a reasonable period of time building major versions that are actively being maintained.
For quite a while I supported xerces 1 and 2. And xalan 1 and 2. Now gump supports 3 versions of Tomcat, and two versions of turbine and soap.
As long as James depends on an unreleased version of a sandbox component of Avalon, then I plan to be obstinant.
- Sam Ruby
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
