My firm belief is that you have many separate jars. otherwise commons-util will become this huge jar that no on understands. But commons-util should still exist IMHO.
and yes, JJAR is indeed necessary. Geir, are you hearing this? ;-) Scott On Tue, Jan 29, 2002 at 10:43:33AM +0100, Christoph Reck wrote: > Martin Cooper wrote: > > > > FileUtils seems an odd place to define ONE_KB, ONE_MB and ONE_GB, since > > they're not specific to file size or disk space. Not sure if there's a > > better place, though... > > > > -- > > Martin Cooper > > I'm trying to ge a picture of jakarta-commons land with *so many* > subprojects. I agree it may be useful to separate codec, io, and text > packages to allow central upgrades but yet separate referencing. > > On the other hand, it seems little productive (less commiters on each) > having these packages standalone. I would prefer that these (Base64, > FileUtils, etc.) remain in the commons.utils package. Having one > good choice of utilites package eases the inclusion of the *one* jar. > > Again, having small jars, each with a *very* specific contract, might > be preferable to others. This allows easy putting together the > building blocks one needs. In this case it would be *very* useful to > have jjar handle the dependencies (and Gump check the consistency). > > If the Base64, FileUtils, etc. classes are moved into own packages, > these should move quickly out of the sandbox into a release - hey > these are mostly copies of working packages that have own carma to > live! The files should then be removed from the original places > (rupert, commons-utils). > > Is this the general consensus on how it should be done within commons > land? Then lets avoid duplicates within: either leave in utils or > remove it from there and finalize jjar... Hey, I'm not pushing, just > trying to keep things clean and crisp for easy digestion :) > > -- > :) Christoph Reck > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- Scott Sanders - [EMAIL PROTECTED] -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
