Re: Gump and Jaxp?

[email protected] wrote:
> 
> 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.sh = bootstrap

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...  ;-)

> Frustration often gets fixed....

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.

> 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