See interspersed comments, but I'm overall quite +1 on this.
On Wed, 28 Mar 2001, Waldhoff, Rodney wrote:
> Here's one of the proposals I was talking about in my earlier email. I
> thought we could kick it around a little bit before submitting a real
> proposal.
>
> The current code base only has one class, used by the object pooling
> package, but I think there is a lot of stuff buried in other Jakarta
> projects that could be moved here pretty readily.
>
> For the time being, the package can be found in the bundle at
> http://www.webappcabaret.com/rwald/commons/. I'll move it into the sandbox
> when I get access.
>
My personal feeling is that you shouldn't *have* to go through the sandbox
first if a proposed Commons component is accepted, but you are certainly
free to do so if you want to experiment a little before proposing the
resulting code.
> Comments?
>
> - R.
>
> ---------------------------------------------------------------------
> Proposal for Collections Package
> [Revision: $Id:$]
>
> (0) Rationale
>
> The Java Collections Framework (as introduced in the 1.2 release of
> the Java platform) provides a set of abstract data type interfaces
> and implementations that provide both a wealth of useful
> functionality, and a solid foundation for extending that
> functionality.
>
> Many Jakarta projects have needs or design criteria that extend
> beyond the core Collections API, such as introducing new abstract
> data types (e.g., Avalon's BinaryHeap) or changing the behavior of
> existing abstract data types (e.g., Struts' FastHashMap).
>
> In keeping with the spirit of the Collections API and of abstract
> data types in general, these components can and should be shared
> assets. A Commons package for abstract data types would provide
> encourage the development and reuse of a robust set of collections
> classes.
>
> (1) Scope of the Package
>
> The package will create and maintain a set of collections and
> related classes designed to be compatible with the Java Collections
> Framework, and to be distributed under the ASF license.
>
Would it be fair to explicitly restrict classes in this package to being
implementations of one of the Collections APIs (or be a support module for
such implementations)?
> (2) The Initial Source of the Package
>
> The initial codebase was harvested from existing and purposed
> Jakarta packages, including the Commons Database Connection Pool,
> Struts[?], Avalon[?], [etc.?]
>
Struts definitely has a few to throw in to the mix.
> (2.1) The Base Name of the Package
>
> Following the Java Collections Framework packaging,
> org.apache.commons.util.
>
As agreed on the mailing list, org.apache.commons.collections is best.
> (3) Jakarta Commons Resources to be Created
>
> (3.1) Mailing List
>
> Until traffic justifies, the package will use the Jakarta-Commons
> list.
>
> (3.2) CVS Repositories
>
> For the time being, the package will use a root branch of the
> Jakarta-Commons CVS repository.
>
> (3.3) Bugzilla
>
> The package should be listed as a component under the Jakarta-Commons
> Bugzilla entry.
>
Thanks for the reminder .. I just created the Bugzilla components for
Commons and BeanUtils. I'll add new packages as they are approved.
> (3.4) Jyve FAQ (when available)
>
> commons-collections
>
> (4) Identify the Initial Set of Committers
>
> Rodney Waldhoff
Count me in!
> [Avalon, Struts, Turbine, etc. representatives?]
> ---------------------------------------------------------------------
>
Craig McClanahan
