I think it is becoming time to discuss trimming down gump runs, and I don't mean by excluding projects from the main. I think we need to consider clusters of localized gumps.
I run local gumps for a few reasons: 1) To build all my "private" stuff (in local CVS repos, lots of changes) 2) To build all my "open source" stuff (to look for errors in my stuff/projects) 3) To build all my "dependencies" a "full" stack (i.e what I can get away with, trimmed down). As such, I run three gumps (and heck, I tried 6 w/ a python set.) I don't gump the absolute full set because (1) I don't have the resoruces (2) I am impatient and don't have the time (if/when I want a quick re-run). As such, I use "packages" along with builds. Unfortunately "packages" have recently become even more awkward than they have been. These days one requires a <project name="X package="..." plus a <module name="X -- to get the list of <jar outputs. If the X exists as project/X.xml that is taken, but if it contains an <ant tag it tries to build. If the gump module descriptor changes (and add/changes jars -- or if the jrs have a @DATE@ in them) the module is out of synch with the package & fails. Even if one copies the module X.xml and edits out the differences, they project/X.xml is taken in preference. Editing in the project/X.xml is a recipe for disaster w/ CVS <<<<< merge problems in your future. Recently, if a package is out of synch with the module gump completely drops all jars for that package, and causing broken builds. Basically, gump and packages are not playing nicely these days. I know Nick did some work to try to create "package" descriptors from module descriptors, and maybe this has a future, however I think that gump needs to fully recognize this need, and fully respect the package. I think a <package name="X" with <jar and such is in order. Public gump (with resoruces) is great for a full stack, but the rest of the world needs support for a selective stack. regards, Adam
