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 <gudnabr...@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] :) >>> --- >>> 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-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
