It appears that this situation involves a plan to deprecate something that hasn't been released yet. This seems backwards to me. No matter how stable or great the primitive collections have proven to be, they haven't been released, so I think it's of utmost importance to make the right decision here. Releasing these classes only to deprecate them in a few months isn't any better for users then keeping them in the sandbox for a few months until they are promoted and released. Actually, I think the latter is better.
Maybe a larger [vote] is required but I think that moving the primitive collections out will be better in the long run for everybody. The benefit of releasing these classes as part of collections 3.0 isn't apparent to me.
Stephen Colebourne wrote:
From: "Rodney Waldhoff" <[EMAIL PROTECTED]>
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.
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.
I want to be clear that I have no problems with the quality, stability or user-base of this code. Good code should be released and used.
I see this as independence, rather than ghettoization, and I believe it to be in the best interests of both areas of code.
My regret is that I did not fully consider the implications of including the primitive packages in collections at the outset. Simply counting java files shows that the primitives packages are now about 50% of [collections]. And there are no Map implementations yet, or decorators other than a few unmodifiable ones.
In addition the release notes factor weighs on my mind. The document describing the release will be very large just with objects, and naturally breaks into two.
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.
Although I can understand how this appears, I was uncomfortable with the primitives code in [collections] before starting the sandbox primitives. Clearly I should have raised my concerns earlier.
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.
OK I'll make a proposal: 1) We create a new commons-proper component pcollections? to maintain primitive collections. 2) Code is copied into pcollections, renaming the package. (or maybe it could keep the same package?) 3) The code in collections is deprecated, with a snapshot jar being made so backwards compatability works. 4) [collections] produces a commons-collections-tests.jar file to enable the tests to work. This contains only the abstract test class framework from collections. I am willing to do most of the work.
Stephen PS. The ant script should be reverted now.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
