commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <bay...@generationjava.com>
Subject Re: [util] Dependency on lang
Date Fri, 22 Nov 2002 08:41:08 GMT


On Fri, 22 Nov 2002, Ola Berg wrote:

> But given the closeness between them, isn't it already now justified
> to manage both the o.a.c.lang and the o.a.c.util package in the
> thought of basic commons component named [core]? They are both small
> and very very very basic. Handling them as two
> jars/subprojects/downloads seems to be so much work for so little
> achieved.
>
> I say: let's marry them together. What do you think?

I'm not sure. Shouldn't util get to being a releasable component on its
own legs before we talk of a Core?

Util's current structure [ignoring current suggestions of things to add to
Util]:

empty http, exception and compare directories.
an lru package which has an LRUStore in, which I'm assuming is not desired
in Collections, but ought to go in there. [I don't get if there's a major
difference between LRUStore and LRUMap, haven't really looked].  [btw, No
apache license on these]

Then there are a handful of classes lying around:

BitField		Seems to have justification for being here.
GenerateUniqueId	Will fold into the Pattens code being migrated in.
Interpolator		Came out of StringUtils.
       			Not worth its existence at the moment.
WordWrapper		Came out of StringUtils. Not stable and
			effectively needs heavy unit testing.
XmlUtils		Probably shouldn't be at Jakarta. Quietly die.
StopWatch		Needs unit testing.

[new]

Ola's Hash stuff.
Patterns' Sequencer stuff.

...

These two new components both feel like good Util things, and hopefully
they can fill the Util project out a bit. We need to clean Util again,
then let things gestate a little with new ideas before releasing it,
either as util or into lang or into core.

Hen




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