commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Heuer <heue...@acm.org>
Subject RE: Commons-Collections enhanced with Java Generics Support
Date Tue, 24 May 2005 16:31:11 GMT

James Carman wrote:

> 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?

With a nod to "Rules for Revolutionaries" [1] I think it makes the most
sense to branch commons-collections.  This should be a lot easier process
now that the repository is in subversion.

The biggest obstacle to overcome is the lack of interested commons
committers to coordinate non-Apache developers, to merge different
implementations (there is a second 1.5 collections implementation at
collections15.sourceforge.net), and address some of the problem areas in
the generic conversion process, e.g. MultiMap.

   michael

[1]  http://incubator.apache.org/learn/rules-for-revolutionaries.html


> -----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
>
>



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


Mime
View raw message