> > 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? >
What makes the Excalibur pool different/better? We start talking about it to see what to do: - Can we condense/refactor to just one? - Do we need both? - Is one better/more useful than the other? We just need to start talking about it :) All of this is just an email thread away ;-) IMHO the synch primitives would go with the threading proposal in the sandbox. Do your primitives look like these? How are they different? I am actually excited about commons and Avalon/Excalibur working more closely to each other. Sam came in with Gump and managed to get the APIs to stabilize, now we need another level of cooperation. I think that this can make it happen. As an aside, I have now read the "Developing with Avalon" paper and I must say that is the best description of a framework that I have ever read. Excellent work! Scott -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
