Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Received-SPF: pass (hermes.apache.org: local policy)
Message-Id: <200505241539.j4OFdMnJ015842@carmanconsulting.com>
From: "James Carman" <james@carmanconsulting.com>
To: "'Jakarta Commons Developers List'" <commons-dev@jakarta.apache.org>,
        <skitching@apache.org>
Subject: RE: Commons-Collections enhanced with Java Generics Support
Date: Tue, 24 May 2005 11:39:32 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
In-Reply-To: <1116947519.3839.67.camel@localhost.localdomain>
Thread-Index: AcVgcu0UdZqHhbGgSp+v5bOy2lwTIwAAxFvw

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:skitching@apache.org] 
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 <james@carmanconsulting.com> 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org