> From: Berin Loritsch [mailto:[EMAIL PROTECTED]] > >>From: Berin Loritsch [mailto:[EMAIL PROTECTED]] > >>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:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
