Geir Magnusson Jr. wrote: > >> My rationale was that the goal of GUMP as I understand it now, is to >> ensure that all projects play well with each other in term of >> compatibility. It seems natural to extend it so that it can also be >> asked to retrieve all dependent jars for a given project. > > Not to me. Gump to me is an early warning tool to ensure API stability > across dependent projects, and must, by definition, always work on the > current bleeding edge of all projects. It must do this because once you > test a set of released versions, nothing changes :) > > So gump doesn't even have the dependent jars for the released versions - it > uses more bleeding edge jars it makes itself to satisfy the dependencies.
Gump can and does use jars checked into cvs: http://jakarta.apache.org/builds/gump/latest/cvsjars.html Gump can and does use jars installed on the machine: http://jakarta.apache.org/builds/gump/latest/packages.html Many of the nightly builds for various subprojects are published based on what gump produces in the manner desired by the communities for these subprojects. Many of these include in bundled form the jars referenced by the build. For more information on what the goal of Gump is (or more precisely, why it was written), please see http://jakarta.apache.org/gump/why.html - Sam Ruby -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
