commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rodney Waldhoff <>
Subject Re: [collections] jar file names
Date Wed, 01 Oct 2003 12:38:39 GMT
On Tue, 30 Sep 2003, Stephen Colebourne wrote:

> My aim with this change was to keep the name commons-collections
> for the object only jar. Unfortunately it was late and I read
> the ant file as only producing two jars, one object and one
> primitive. Also, I had thought that was what was agreed
> (ie. no combined jar file).
> To be clear this time, my choice for jars is for:
> - commons-collections.jar - object only as it always
> has been
> - commons-collections-primitves.jar - an optional
> additional jar of primitives
> No combination jar, as that leads to
> classpath/version issues.

Commons-collections.jar hasn't always been "object only", indeed, up until
three days ago it contained the primitive collections, as it has since
they were first committed nearly 18 months ago.

I'm not strongly opposed to commons-collections.jar excluding the
primitive collections, as long as some all-inclusive JAR is available.
I'm not sure why you're trying to prohibit that.  A number of projects
(e.g., log4j) and components (e.g., commons-logging) distribute
overlapping JARs without signficant problems.  I'll suggest these
"classpath/version issues" are a hyptothetical problem.  I don't imagaine
anyone is going to be profoundly confused as to whether or not
commons-collections-all.jar contains all of commons-collections.  But as
we saw yesterday, not providing a complete JAR has caused actual classpath
and versioning issues.

> Of course, my view remains that primitives are a
> specialised extension to collections, not part of
> the main code. As you know, I don't believe that
> they should be directly managed with [collections].
> For example, I was going to invite you to write
> the release notes for primitvies, as you are
> the only coder in those packages.
> You need to understand that I am far from
> comfortable with managing/releasing these
> classes in this way. Despite being release
> manager, I sometimes feel like -1ing
> my own release.

Don't do anything you're not comfortable with, but frankly I'm beginning
to resent repeated attempts to ghettoize this code base.  The primitive
collections have just as many committers, and quite likely more users, as
other collections sub-packages (notably collections.observed.*). They are
designed around real-world user experience. They have 100% test coverage.
They have been stable for nearly 9 months.  Just because you personally
aren't interested in using this code (or more accurately, just because
you're interested in exploring alternative implementations of this code)
doesn't justify ostracizing it from the rest of the package.  You're
trying to make the primitive collections a second-class citizen here.

As before, if you want to make primitive collections a first class citizen
in another commons proper component, then propose that, but it will
require some extra work to extract the shared bits from the
commons-collections code base.

> Stephen

- Rod

PS: Now maven and ant generate different commons-collections.jar files,
by the way.

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

View raw message