Costin Manolache wrote:
>
> One compromise may be to use a separate CVS only for binaries, with the
> latest "released" version of each product.
>
> Users will have to check out the project cvs and the common binaries CVS.
>
> Benefits over checking in binaries in all projects:
> - only pristine sources in all projects ( except the binary tree )
> - consistent behavior and location for the binaries for all projects
using
> the binary tree
> - less duplication and space ( and download time )
> - a simple way to get the latest stable release for all jars ( a cvs
> update will also get only what's changed, instead of requiring to
> download and install x different tar.gz files )
+1
Perhaps we could even get a change into ant.bat and ant.sh to "
-Djakarta.home=$JAKARTA_HOME".
> - Sam may be happy ( as gump could create the binaries instead of
checking
> out, so it would be as easy to build with the "latest and greatest" )
> ( it would also be easy for developers to do both types of builds - if
the
> location of the "binary" tree is configurable )
Sam already is happy - and those binaries should be built by the release
ownwers by whatever process they deem appropriate.
> Problems:
> - user has to checkout 2 trees
Oh, the humanity! An extra command! Whoa is me! We can't expect our
*DEVELOPERS* to be able to handle this, can we?
;-)
> - all projects will be forced to use the latest stable release ( but this
> can be a big benefit ! )
That's actually a serious concern. There are projects like Turbine and
Avalon that are in a continual state of flux. At least now the Avalon
consumers are now marching in lock step, but in general one can not mix and
match just yet. That's the real problem that we need to solve.
> - you may get more binaries than you need for a project
I'd actually get less. ;-)
- Sam Ruby
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
