commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <>
Subject Re: Commons Util 1.0 release candidate 1
Date Thu, 21 Feb 2002 16:27:27 GMT

Following on from some of the other mails, I'm tweaking my suggested
changes to be inline with other suggestions.

The Utils sub-project would stay where it is as a clearing-hosue for
miscellaneous small classes without obvious targets and would remain in
the sandbox.

A handful of classes would vanish or migrate into the Commons.Collections

> EnumerationIterator, MapUtils, CollectionsUtils SequencedHashtable
> StringStack

This would require a Collections/Utils commiter preferably to handle the

A new project called 'lang'. This would contain:

>     Classes Numbers Objects Strings
>     possibly Base64, though Email and Codec both have this.
>     package 'exception' would be in this with its 4 classes.

Lang would need to be proposed, so the first step would be someone to
propose it and the necessary number of committers for the proposal. I've
worked a lot on these classes, so would be happy to make the proposal.

An already existing project named 'io'. The main developer for this (is it
Scott?) would need to confirm that:

>   Files Streams LockableFileWriter

are currently the same in both projects and the Utils ones may die.

This leaves a few other classes to decide where they should go.

1) xml. Currently there's one class here. I plan to add an XmlWriter and I
do have a parser I could add, but as it's not dom/sax etc I see little use
in it being there. Is it worth looking at seeing what common components
the project has for Java. Maybe they haven't merged them
together yet and need assistance. I also plan to add more code to the
existing class.

2) http. I imagine this would either go into io or into HttpClient. io
seems most likely as HttpClient has a different goal. How does that sound

3) 'util' like classes.

>    Soundex GenerateUniqueId BufferCache

Soundex is used by Strings(StringUtil) so it's tempting to send it with it
into Lang. Strings has some hidden subclasses too, one of which is
Metaphone and would ideally go wherever Soundex goes. GenerateUniqueId is
pretty much util stuff. BufferCache sounds like it might be deprecated


On Wed, 20 Feb 2002 wrote:

> On Wed, 20 Feb 2002, Daniel Rall wrote:
> > > So I would suggest:
> > >
> > >;
> > >
> > > org.apache.commons.javax.xml.Xmls
> > >
> > I'm in favor of this change.  Bay, will you do the deed?
> I'd be happy to once we get a good consensus on the change to Utils'
> structure :) I'm a great believer that the package naming and class names
> are more important than the initial implementation, I think that's
> because I'm a librarian at heart.
> Another email has suggested that using the word java is bad. I am happy to
> agree on this one as it means too much break with tradition.
> So a re-suggested change would be:
> org.apache.commons.util.lang:
>     Classes Numbers Objects Strings Base64
>     Files Streams LockableFileWriter
> org.apache.commons.util:   [util.util seems redundant]
>     Soundex GenerateUniqueId BufferCache
> org.apache.commons.util.xml:
>     XmlHelper[new name? Xmls does seem ick]
> EnumerationIterator, MapUtils, CollectionsUtils all removed and the Util
> project made dependant on the Collections project. SequencedHashtable
> removed and BufferCache made to use a Collections version
> (SequencedHashMap?)
> Also, StringStack to goto the Collections project. Potentially a request
> made to the Collections project to consider renaming
> CollectionUtils/MapUtils/other-of-this-type. Although having one called
> Collections and Arrays has some issues perhaps.
> Lastly, exception/ and http/ sub-packages to remain as they are, except
> that http.HttpUtils would need renaming. Https seems misleading, so
> HttpHelper or some other name would make sense. This could be a bad side
> for the idea of pluralising the class names if we keep coming across ones
> it doesn't fit.
> Once the renaming is made, then the question arrives of whether everything
> should go into the main cvs, or if a sandbox should be kept. Is there a
> reason why a project can't have a sandbox and a normal dir with the same
> package names in? Or is the extra indirection not necessary? Would all
> classes in the main cvs be considered to be a part of the project when it
> has a 1.0 release?
> Sorry for the launch of questins at the end there.
> Bay
> --
> To unsubscribe, e-mail:   <>
> For additional commands, e-mail: <>

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message