commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scott Sanders" <ssand...@nextance.com>
Subject RE: Clearing the air regarding Avalon utilities and Commons
Date Wed, 26 Dec 2001 19:33:27 GMT
> From: Berin Loritsch [mailto:bloritsch@apache.org] 
> >>From: Berin Loritsch [mailto:bloritsch@apache.org]
> >>I would like some more information and clarification on the 
> >>Jakarta Commons charter and practicalities of placing code 
> >>there.  Avalon Excalibur's code is fairly integrated, and is 
> >>a testimony to how well the API works.  However, because it 
> >>is easier to use the concurrent package synchronization 
> >>primitives rather than using the "synchronized" keyword all 
> >>the time, I have used them to implement thread-safe pools, 
> >>among other things.
> >>
> >>As far as I can tell there are separate packages for pooling,
> >>synchronization primitives, and other utilities.  My 
> >>understanding regarding the charter is that you don't want 
> >>cross library dependancies in Commons.  Were I to advocate 
> >>moving the utilities in Avalon Excalibur to Jakarta Commons, 
> >>how would that work itself out?
> >>
> >>For instance, the new Pool implementations that I am writing
> >>are based on the new Buffer classes and use the 
> >>synchronization primitives.
> >>
> > 
> > Does this mean that the buffer and sync primitives would also be 
> > submitted to commons?
> 
> 
> Sure, the Buffer would go in Collections for example.
> 
> I mean there is alot of utility code in Excalibur, from file 
> utilities to queue implementations.
> 

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?  

Scott

--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message