commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christoph Reck <>
Subject Re: Commons Util 1.0 release candidate 1
Date Thu, 21 Feb 2002 10:35:49 GMT
+1 (even though I'm not a commiter - maybe this is the chance for me
    to become one - e.g. to do bay's proposed naming change?)

Bay's proposed change below makes good sense. XmlHelpers or XmlUtils
are equally good to me...

Note that in the sandbox org.apache.commons.util.FileUtils already
have been copied out into, which I
challenged with some unanswered questions in another thread. Within
this thread (was it Michael or Scott?) it was again proposed to 
remove the ...utils... level (which has been already done for 
some classes into own sandbox packages - but these have not yet been 
moved out of the current commons.util package). If the utils 
commiters agree in putting these in own (promoted) commons packages
this would be a solution - but I questioned if it would be confusing 
to have so many top-level commons packages. I'd rather recommend
leaving these in etc.

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

:) Christoph Reck

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

View raw message