commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <bay...@generationjava.com>
Subject Re: Commons Util 1.0 release candidate 1
Date Thu, 21 Feb 2002 04:50:53 GMT


On Wed, 20 Feb 2002, Daniel Rall wrote:

> > So I would suggest:
> >
> > org.apache.commons.java.io.Urls;
> > org.apache.commons.java.lang.Strings
> > 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

org.apache.commons.util.io:

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


Mime
View raw message