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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
