commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christoph Reck <Christoph.R...@dlr.de>
Subject Re: cvs commit: jakarta-commons-sandbox/io/src/test/org/apache/commons/io IOTestCase.java
Date Tue, 29 Jan 2002 09:43:33 GMT
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:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message