Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (nike.apache.org: domain of flamefew@gmail.com designates
 74.125.92.149 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=LgE5vAShROBkqlJ44KavN07OZ+QHjjf2sl478MYjpaFYsaiqGJU1+MTl5m1FE457ld
         rYp+CIBs548FnrpjwIiLJC7Eb0pnnCE3L5tZd1EjzCZrd1h6/3MRXgqyftqhW71tDEEZ
         7z418YeIgt847T8r2OE2P8KVqBmxiNnKq8fkk=
MIME-Version: 1.0
In-Reply-To: <b9e663071001071447o244da5d2tadf160570d870223@mail.gmail.com>
References: <31cc37360912300218h450c517es8170702e9ea8fa96@mail.gmail.com>
	 <4B43EE5D.8030703@btopenworld.com>
	 <6292344D-89CA-404D-9B54-9FACFA01D406@gmail.com>
	 <b9e663071001071447o244da5d2tadf160570d870223@mail.gmail.com>
Date: Thu, 7 Jan 2010 23:22:18 -0800
Message-ID: <31cc37361001072322u669ba9beld54af343c1378950@mail.gmail.com>
Subject: Re: [lang][collections] Overlap; Collections thoughts
From: Henri Yandell <flamefew@gmail.com>
To: Commons Developers List <dev@commons.apache.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

How would that work?

If I do work on one component and want to release it, do I have to
wait on 7 other releases?

Multiple artifacts is going to encourage growth, but without separate
release cycles it's going to create release stagnation.

I'd suggest figuring out what the dependency tree is before worrying
on this one. We already have internal commons dependencies without the
desire to create a compatibility matrix (configuration for example
depends on lots of components and its pom.xml plus an understanding of
version numbers covers compatibility).

Hen

On Thu, Jan 7, 2010 at 2:47 PM, Paul Benedict <pbenedict@apache.org> wrote:
> But not splitting into separate releases, just separate artifacts. As
> stated before, separate releases creates a compatibility matrix. These
> aren't separate projects, but different areas of one.
>
> On Thu, Jan 7, 2010 at 2:56 PM, Matt Benson <gudnabrsam@gmail.com> wrote:
>>
>> On Jan 5, 2010, at 7:58 PM, Stephen Colebourne wrote:
>> [SNIP]
>>>
>>> And splitting [collections]? Definitely a good idea. I would remove all
>>> the Predicate/Closure/Transformer code (if you believe in FP, use
>>> [functor]). Then split the rest by implementations of JDK collections, =
and
>>> extended JDK collections - BidiMap, Bag, Trie.
>>>
>>
>> +1 as I doubt any more reasonable approach exists.
>>
>> -Matt
>>
>>> Stephen
>>>
>>>
>>> Henri Yandell wrote:
>>>>
>>>> Overlap between Lang and Collections is starting to increase a bit.
>>>> Requested items for ArrayUtils (LANG-238, LANG-470) are better
>>>> implemented imo as an ArraySet class. An easy add to Collections.
>>>> ComparableComparator made its way (privately) over for the new Range
>>>> class. Fair enough - Comparable and Comparator also overlap between
>>>> lang.* and util.*.
>>>> I have a JIRA issue threat to consider moving Collections code over to
>>>> Lang if Collections becomes dead [LANG-532] =A0:)
>>>> ---
>>>> One thought I have for Collections is splitting it up into two parts.
>>>> The first would be items that add to collections in the JDK, the
>>>> second would be additional collections. The former could conceivably
>>>> merge with Lang, the latter could also be split up into an SPI style
>>>> approach with an API jar and an Impl jar. The latter would most likely
>>>> depend on the former.
>>>> It would then be tempting to also merge Functors for example into the
>>>> latter, plus I think we could get back on the bandwagon of adding new
>>>> things, like the long standing Trie JIRA issue.
>>>> Biased note: Part of this is that I'm interested in the JDK enhancing
>>>> parts, but not all the implementations of weird and whacky
>>>> collections; however I think this is likely not just me and that the
>>>> separation would do wonders for the release cycle.
>>>> Thoughts?
>>>> Hen
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

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