Ainsi parlait Dirk-Willem van Gulik : [..] > The next step - fixing things can take more time: > > 2. Getting our code to work again. > > Option 1.1 > Each project put's their jar's back in - but > according to the guidelines below. > > Option 2.2 > We create a 'xml-third-party' repository for > all the third party jar's. Following the > guide lines below. > > So we keep all 3rd party and alien code in > one place. Option 2.3: Don't import any jar back into the cvs, but fills a complete and exact dependency list -)
Ok, not exactly what you're looking for, but at least it could open the debate. Outside of java world, i never saw any binary in CVS. Instead there are README files telling: you need libfoo-x.y.z and libbar-x.y.z to build this soft. Putting dependencies in CVS is nasty because: - you make release tarballs biggers - you end up with lots of duplicated files on your box - you give headache to external people wanting to package the soft properly for computing exact dependencies (but what version of foobar is this foobar.jar exactly ?) - you can't follow external dependencies evolutions, as you use a static one So, why not profit of the big CVS clean-up to adopt more coherent practice ? -- Guillaume Rousse <[EMAIL PROTECTED]> GPG key http://lis.snv.jussieu.fr/~rousse/gpgkey.html --------------------------------------------------------------------- In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
