These issues came up when we formed the commons. For example, I was looking at the connection pooling implementations in and around Jakarta, and none of the three I could find at the time (Turbine, Struts, Avalon) were packaged to be used independently.
Some were technically free of their home framework, but still didn't have docs, examples or clear support/participation channels. One of the things we hoped that commons would indeed be was a place for components to live, so that frameworks could share them. It's worked that way a little, one or two things from Turbine, some new ones and what appears to be a dismantling of Struts into a lightweight controller rather than a web app framework :) We can't force anything, nor do I think we would ever want to. The people behind the code in each of the projects have to want to both to it as well as want to support it.... On 12/22/01 2:09 PM, "Vincent Massol" <[EMAIL PROTECTED]> wrote: > I'd like to have your opinion on the possible synergies between Avalon > and the Commons projects on reuse and sharing. > > Here are some of my thoughts :-) > > * Avalon is a service framework (ok, component and service framework) > and is suited for lots of projects but some projects may not need/want > to use the small Avalon wrapper which is layered on top of the java > classes and may want to use directly the implementation (like using a > jdbc pool but not as an Avalon component which needs to be managed by a > component manager) > > * On the other hand, Commons is geared towards providing context neutral > libraries which could be used in any context. > > * Thus, one solution could be to put in Commons the bare implementation > (like the jdbc pool implementation) and put in Avalon a component > wrapper on top of it (and reference the commons jars). > > * Thus, the bare implementation can also be used independently of > Avalon. > > * For example, we could easily provide an Avalon component which would > wrap around the commons digester, etc. > > What do you think ? > > If there is an agreement, this should probably be done slowly, one > library at a time. I guess, I'm not sure about the knowledge both > projects have of each other. I have been using both and I see a lot of > possible code reuse/benefits. > > Thanks > -Vincent > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." - Benjamin Franklin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
