Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@apache.org Received: (qmail 16734 invoked from network); 26 Dec 2001 19:53:39 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 26 Dec 2001 19:53:39 -0000 Received: (qmail 9528 invoked by uid 97); 26 Dec 2001 19:53:41 -0000 Delivered-To: qmlist-jakarta-archive-commons-dev@jakarta.apache.org Received: (qmail 9381 invoked by uid 97); 26 Dec 2001 19:53:39 -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 9356 invoked from network); 26 Dec 2001 19:53:38 -0000 Message-ID: <3C2A2B41.4000401@apache.org> Date: Wed, 26 Dec 2001 14:55:45 -0500 From: Berin Loritsch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.7) Gecko/20011221 X-Accept-Language: en-us MIME-Version: 1.0 To: Jakarta Commons Developers List CC: Avalon Developers List Subject: Re: Clearing the air regarding Avalon utilities and Commons References: <458473676F1AC74A84EAB2F22004DA6DD7B3@mail.nextance.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Scott Sanders wrote: >>From: Berin Loritsch [mailto:bloritsch@apache.org] >> > So then you start moving it over. In commons everything is broken out > component-wise, but this is nothing new. Let's start talking about how > to go forward with whatever you/we feel should be in the commons. I see > commons as a bunch of components, but I tend to NOT see a framework in > commons. > > So let's get all Excalibur's and Avalon's utility code into commons, > then Excalibur still uses it, and commons doesn't have to rewrite > (although rewriting seems to be the jakarta way, IMHO). Everybody > should win. Right? Theorhetically. Now Avalon utilities include a pooling implementation that is nothing like the Pool package in Commons. Should the new pooling package be moved in with that? And then what about the synchronization primitives? Do we know where they would go? -- "They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." - Benjamin Franklin -- To unsubscribe, e-mail: For additional commands, e-mail: