commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam R. B. Jack" <>
Subject Re: [collections] new snapshot to ibiblio
Date Fri, 14 May 2004 14:49:35 GMT

> > My impression was, GUMP always use the cvs-head to build the
> > dependencies - and fixing the dependency to a given release
> > is not the intention of GUMP.
> >From experience, I can tell you that I welcome the new ability to fix
> certain dependencies.  For example, the Avalon Project has made API
> that break compatibility with existing code.  James ships with an earlier
> version of Avalon because of the incompatibility.  Eventually, James will
> make the necessary changes, but that will happen on James' schedule, not
> Avalon's.  But James also ships with Jakarta Commons DBCP, and will be
> other Jakarta Commons packages.  If James were forced to track the HEAD of
> all components, even when some of them are known to be incompatible, there
> would be no point in using GUMP, since failure can be assumed.  However,
> with the new ability, James could fix the Avalon dependencies to the
> particular version(s) used, and still track HEAD for other dependencies.

Actually, we need to correct/clarify something for the record. Gump has some
of this already. It can use a CVS tag (or SVN branch) of some module to
allow this.

We used it yesterday because we are waiting for Commons Logging to become
compatible with log4j CVS HEAD (to be known as 1.3).


And for log4j 1.2:
    See: <module name="logging-log4j-12" tag="v1_2-branch"

We set C-L's dependency to logging-log4j-12 from logging-log4j.

Adding the ability to get a dated/frozen build of a project [from a
repository/store] allows further granularity (e.g. we coped with 1.3 up
until X and would like to keep 'closer to' 1.3 than 1.2). Clearly the
combinatorials are theoretically enormous, but (like tags) in practice they
can be made to work.



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message