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