Simon, Suppose we do want to further pursue this (I think we should). How would you recommend we set up the project? Should we branch commons-collections off and start doing releases off of the JDK5 branch along side the main branch? Or, would you recommend creating an entirely new commons project? Or, would you recommend creating a org.apache.jakarta.commons.collections.jdk5 package with the new classes in them and set up the build to conditionally compile them only if using JDK5?
James -----Original Message----- From: Simon Kitching [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 24, 2005 11:12 AM To: Jakarta Commons Developers List Subject: Re: Commons-Collections enhanced with Java Generics Support On Tue, 2005-05-24 at 16:05 +0200, Thomas Dudziak wrote: > On 5/24/05, James Carman <[EMAIL PROTECTED]> wrote: > > Why can't we host this project at ASF? Couldn't we create a new branch for > > JDK5 collections or something? > > +1, though I'd prefer the simple solution of two jars, one for pre-1.5 > and one for 1.5 which contains the generics-support (either version or > add-on jar). This would prevent divergences in future versions as only > one codebase has to be supported. The major reason the project was developed on sourceforge is that the people who wanted to do the implementation were not commons committers, and no commons committers had time to manage the project. I don't know whether the developers (John/Matt) are even interested in the project being merged back into apache at the moment. But if they were, then in order for it to become a commons project (including being a branch of the existing collections project) either some existing commons committers would need to volunteer to commit patches submitted (including being responsible for the quality, licensing, and ensuring longterm support etc) or some/all of the generics project developers would need to be elected as commons committers. But we can't just elect someone as a commons committer without knowing the quality of their work or their ability to work well within commons (esp. having plenty of patience ;-). I think it very likely that Matt/John would be fine additions to the commons team, but we just don't know them yet (at least I don't). If someone had the time to check the collections.sf.net project mail list and review the existing code thoroughly this might be enough to give a +1 on this issue. Or if they have a track record with some other large open-source project. Otherwise the project really needs a few commons committers to work with them for a month or two until we can feel comfortable about electing them. There is also the question of how large the generic collections community will be. There aren't yet a whole lot of projects coding to 1.5 as far as I know. That would mean that it might be hard to ensure a pool of interested developers for this project that would continue maintenance. And that would be bad - commons doesn't need any more zombie projects than it already has. Then again I may be wrong; there might be huge demand for this. Or Matt/John may be enthusiastic enough to provide maintenance over the next year or two until java 1.5 becomes more prevalent. Checking the sf project forums should provide some evidence of whether there is a solid user community for this project or not. Certainly a pool of only two developers is a little fragile for long-term support if there is only a small user pool to draw new developers from. Note that I'm not saying it's impossible to bring this project into commons if Matt/John want to. And I certainly don't mean any offence to Matt/John, who have clearly put a lot of effort into writing code that is available for free and are therefore "good guys" by any definition. But these are issues that need to be addressed before adopting this code into commons. In the meantime, though, I see no harm in making sure we have plenty of references from commons to the collections.sf.net project (see, there's one!) from the commons site, wiki, etc. We can make sure people who might visit commons-collections are made aware of the generics version and then those people can make up their own minds about which code base they want to use. That's just being friendly and helpful. And there's nothing *wrong* with projects on sourceforge anyway. If you want to address some of these issues and push for generic collections in commons then go ahead and put a case that addresses the above issues. Regards, Simon --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
