On 12/26/01 2:55 PM, "Berin Loritsch" <[EMAIL PROTECTED]> wrote:
> Scott Sanders wrote: > >>> From: Berin Loritsch [mailto:[EMAIL PROTECTED]] >>> > >> 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? > We can have a second pool implementation. There is nothing that prevents that. Commons isn't a framework, so there is no requirement that we have just one of anything. The hope though is that there aren't any specific structural requirements to using it (like having to have the rest of the pieces - logkit is an example of something that can be used indep...) On the other hand, Avalon could solve the whole problem though a bit of documentation and repackaging, right? We in Commons have no requirement that Commons things only depend on Commons things. If there was a distinct, documented, supported standalong DBCP in Avalon, I might use it. -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting "Whoever would overthrow the liberty of a nation must begin by subduing the freeness of speech." - Benjamin Franklin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
