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]>
