cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Crossley <>
Subject Re: Cocoon is not gump!
Date Wed, 30 Jun 2004 08:08:44 GMT
Steven Noels wrote:
> Sylvain Wallez wrote:
> >> For third-party, unreleased or patched libs, a coherent naming scheme 
> >> and offloading procedure should suffice.
> >
> > A coherent naming scheme is needed, but is archiving in a central 
> > location necessary (not talking of the infrastructure problems)? When 
> > you decide to deliver a project using a snapshot, that snapshot is 
> > generally a recent one (otherwise its changes are likely to be part of 
> > an official release) and the CVS repository is therefore still 
> > available.
> For "snapshot releases" of dependency libraries, I think adding and 
> versioning separate src jars of these specific libraries to CVS should 
> be enough - and could possibly boil down to a simple jar-up and commit 
> of said library's source code by the committer doing the library 
> upgrade.
> CVS sandbox size shouldn't be a concern IMHO.

Our CVS is already huge. This might frighten away of a lot of
would-be developers. I am lucky because i recently upgraded
from dial-up modem to ADSL. If holding sources in CVS is the
only solution, then so be it.

> - distribution size might 
> be for some, and would hopefully get solved once we split Cocoon into a 
> kernel project and a federation of Cocoon modules|blocks subprojects. 
> Until we are there, we might add an ├╗ber-src-jar build target to the 
> build system collecting source dumps of those libraries and wrapping 
> those into a cocoon-unreleased-dependent-libs.jar we ship along the 
> real distribution.

That is a great idea.

> Since Ralph is very keen on this, maybe he can help to come up with 
> some Ant tasks. ;-)
> </Steven>

View raw message