From dev-return-117517-apmail-commons-dev-archive=commons.apache.org@commons.apache.org Sat Jan 02 17:22:45 2010 Return-Path: Delivered-To: apmail-commons-dev-archive@www.apache.org Received: (qmail 74617 invoked from network); 2 Jan 2010 17:22:45 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 2 Jan 2010 17:22:45 -0000 Received: (qmail 73327 invoked by uid 500); 2 Jan 2010 17:22:44 -0000 Delivered-To: apmail-commons-dev-archive@commons.apache.org Received: (qmail 73200 invoked by uid 500); 2 Jan 2010 17:22:44 -0000 Mailing-List: contact dev-help@commons.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Commons Developers List" Delivered-To: mailing list dev@commons.apache.org Received: (qmail 73190 invoked by uid 99); 2 Jan 2010 17:22:44 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 02 Jan 2010 17:22:44 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of paulus.benedictus@gmail.com designates 209.85.223.185 as permitted sender) Received: from [209.85.223.185] (HELO mail-iw0-f185.google.com) (209.85.223.185) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 02 Jan 2010 17:22:37 +0000 Received: by iwn15 with SMTP id 15so9022717iwn.10 for ; Sat, 02 Jan 2010 09:22:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to :content-type:content-transfer-encoding; bh=XM9bvUm20QKK6ZUGTCww5mWPG5mkTITxfmQa+V3E72A=; b=ntw0zVyvCNqPEe52fuept7zLwTPsBfc5IcQboG0T/Rly8NwxjpgGIewYI1OG9CFiPA 2vBTbsrfKCHzva4Q//SkOBd1nNIGXa7XaQgOAOO5jyXtyp2v2LkOBZqdNccqQFViqoLg Nv9WF8jruiCXQL/KPHFtzzibQXY8kUj6WtA2Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=Ne1Owebjzo21k8Bacuq1aO2r4qmzh2uyYKu5GVkciLoyNVkCHwVKUl9lnBngzBlMOk 6FoyYeLIEvsUJFUnIVgdwjfGHxyM1cjocjwMVjP4LgQFjZ+keSLHm1L+dMq9OG58ad0T 3naqlDiZWCt7FqaUVGd1Qvw51e3akr5ZHviJE= MIME-Version: 1.0 Sender: paulus.benedictus@gmail.com Received: by 10.231.24.142 with SMTP id v14mr870528ibb.55.1262452936986; Sat, 02 Jan 2010 09:22:16 -0800 (PST) In-Reply-To: <4B3F7E2E.6090108@gmail.com> References: <31cc37360912300218h450c517es8170702e9ea8fa96@mail.gmail.com> <4B3F7E2E.6090108@gmail.com> Date: Sat, 2 Jan 2010 11:22:16 -0600 X-Google-Sender-Auth: b94b2fb4011884e4 Message-ID: Subject: Re: [lang][collections] Overlap; Collections thoughts From: Paul Benedict To: Commons Developers List Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I do not like the divide between Lang and Collections. I think it's a superficial divide that can never really be complete, and the forces of logic naturally pulls us back together in some regards. It's consternation to keep these projects separate. Why must we keep trying? I'd like to propose merging the projects and then breaking them down into separate Maven child modules (i.e., distribution assemblies). I'd rather have one release with smaller artifacts. Perhaps we can do this for Commons Lang 3 (or, if we must, wait till 4). Paul On Sat, Jan 2, 2010 at 11:11 AM, Phil Steitz wrote: > 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. > > Interesting idea and forces us to really think about the scopes of > both [lang] and [collections]. =A0Both started as really extensions of > the JDK and both have had large parts obsoleted by advances in the > JDK. =A0I guess it still makes sense to consider [lang] as simple > extensions of the JDK and [collections] as data structures. =A0What I > have a little trouble with is where to draw the line within > [collections]. =A0I think functors is a bad example, as one could > argue that this belongs in neither [collections] nor [lang] - oh > wait, we did that and created [functors] (lets not divert down that > rabbit hole ;). =A0Better examples of what might be peeled off into > [lang] could be the iterators or decorators. =A0Can you get a little > more specific on what parts of [collections] you see as in scope for > =A0merging into [lang]? > > I am +1 on publishing the collections test jar as a separate maven > artifact. =A0We don't have to create a separate subproject for that, IMO. > > Note that lots of other commons components - [math], [net], > [functors], [configuration], [beanutils] all come to mind > immediately - have elements that amount to extensions of the JDK. > Like [collections], they all have a more specialized domain that is > their primary focus. =A0So the natural question is, if this makes > sense for [collections], why not everywhere else? =A0Answering that > question might help clarify intent here. > > One final comment is that a logical alternative is to just split > [collections] internally into multiple pieces with separate release > cycles. Managing dependencies among the subcomponents and user > documentation might be tricky. =A0IIRC, that is what has prevented us > from actually ever doing this up to now. > > > Phil > > >> >> 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