On Fri, 24 Aug 2001, Jon Stevens wrote:
> Date: Fri, 24 Aug 2001 13:25:49 -0700
> From: Jon Stevens <[EMAIL PROTECTED]>
> Reply-To: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> Subject: Re: cvs commit:
> jakarta-commons-sandbox/util/src/java/org/apache/commons/util
> EnumerationIterator.java
>
> on 8/24/01 1:03 PM, "Craig R. McClanahan" <[EMAIL PROTECTED]> wrote:
>
> > As for whether commons-util should have their own copy, that seems a
> > tougher call (although I note that "no dependencies" was part of the
> > original intent). Are there really that many use cases where commons-util
> > would be included and commons-collections would not?
> >
> > Craig
>
> Craig brings up a really going point...how about if we think about this the
> way that Sun thinks about it with the JDK (god, I can't believe I'm saying
> this)...
>
Boy, I can't believe it either :-)
> The JDK has the java.util package. Within it are Collections classes as well
> as a bunch of other stuff that isn't necessarily related to Collections.
> What if we combine commons-util with commons-collections just like Sun does?
>
When Commons was first started, there was some discussion about using the
name "util" or "utilities" for a package like this. The reason we didn't
then is that this name could apply to almost *everything* in commons --
but we wanted the ability to still have fine-grained packages of classes
that worked together, but were conceptually small enough to be understood
separately.
Following the JDK precedent, we'd also see that not everything is in the
"core" java.util package, either (java.sql, java.text, java.util.jar,
java.util.zip). It makes sense to me that we have "commons collection
utilities", "commons string utilities", "commons JMS utilities" (James
Strachan's new sandbox toy) and so on as separate things.
> -jon
>
>
Craig
