Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@apache.org Received: (qmail 58486 invoked from network); 21 Oct 2002 22:54:54 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 21 Oct 2002 22:54:54 -0000 Received: (qmail 899 invoked by uid 97); 21 Oct 2002 22:55:47 -0000 Delivered-To: qmlist-jakarta-archive-commons-dev@jakarta.apache.org Received: (qmail 869 invoked by uid 97); 21 Oct 2002 22:55:46 -0000 Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Jakarta Commons Developers List" Reply-To: "Jakarta Commons Developers List" Delivered-To: mailing list commons-dev@jakarta.apache.org Received: (qmail 849 invoked by uid 98); 21 Oct 2002 22:55:45 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) Message-ID: <003501c27954$ece46500$144a29d9@oemcomputer> From: "Stephen Colebourne" To: "Jakarta Commons Developers List" References: <3DB45234.1060004@apache.org> <00fb01c2793a$96fe2fa0$296178d5@oemcomputer> <1035235856.1169.53.camel@swami> Subject: Re: Apache commons [was:Re: Naming issues] Date: Mon, 21 Oct 2002 23:55:17 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N > I can see some good use of an apache-commons : > > 1) Projects that are implementing eg RFC's that is not language related > can commonly discuss implementations, have their API's (where usefull) > about the same. > 2) Joining expertise > 3) Clear for the outside : want an http common implementation go to > http://blah and you find all the possible implementations there Part of the issue is about the different *types* of (sub sub) projects we have in (jakarta) commons. Collections/IO/Util/Pattern/Lang potentially make quite a close group (eg. same committers). JXpath/CLI/HttpClient are much more independent of each other, just sharing the same space (eg. different committers for each). Apache commons doesn't help this, it makes it worse. > 1) Decisions will be a great pain, unless the specific languages can > acutally make decisions on their own. > 2) It can get messy in ML's with language specific issues, not even > speaking about not very interesting commits from the c part of the > project I would set my mail filter so all C and Perl messages go straight to trash. > apache-commons should be there for the outside and for joining > expertise, so mainly containing a website + mailinglists. > This way nothing changes, just some things get added. > The problem with this can be however who will bring parties together in > such an effort ;)) Now, if Apache Commons were 1) Just a 'federation' of commons type Apache projects (as per the original reorg proposal) 2) Not called commons that'd be just grand. Stephen -- To unsubscribe, e-mail: For additional commands, e-mail: