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 Wed, 30 Jan 2002 14:51:51 GMT
Scott Sanders wrote:
> 
> 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.

The point that I wantend to make is that is something is moved from
within one commons package to a standalone commons package, it should
be promptly deleted there to avoid confusion, duplicate bugfixes and
enhancements. In my case I +1ned the transfer of FileUtils from rupert 
to utils by jvz, and now scott moved it to io, now we have three
copies in commons and IMHO this needs clearing up!.

The second point if such (hopefuly tested) utilites get a top level
commons slot, they should quickly move out of the sandbox and into
a release.

Another problem I'm facing with an application I'm creating right now,
is that including many jars with no webapp-like automatic classloader 
I run into "word to long" and similar command-line and shell limits. 
So I'm figuring out how to use the URLClassloader in a configurable 
way to run my application in WIN/UNIX/JavaWebStart, etc.

:) Christoph

> 
> 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:commons-dev-unsubscribe@jakarta.apache.org>
> > For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>
> >
> 
> --
> Scott Sanders - sanders@apache.org
> 
> --
> To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>

-- 
:) 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