All,
> > Just speaking philosophically (and not about any particular decision), > > what do people think of this approach: when we hit a piece of the > > Avalon codebase (framework, excalibur, what-have-you) that we're unhappy > > with, then we make a copy of it, possibly even repackage it, add it to > > James, and make the code work for our needs. Often we will know a small > > piece is not working, but may not know the perfect solution until we use > > it in James for a while (a few test runs, maybe a few months). I think > > we would benefit by not getting (feeling) stuck waiting for an Avalon > > release, and the Avalon projects would benefit with more people building > > components. This can be done as healthy competition, and if we > > ultimately figure a better way to build a component, we can certainly > > pass it back to Avalon's codebase. > > +1 > > this isn't far different from the way we might use OS code if we were a > commercial company building a product. > As long as we contribute improvements back to Avalon, and don't just rip > it off, then I'm cool with that. +1 Yep. And this is exactly what we've been doing. If you check out the SimpleConnectionManager you'll note comments in the Javadoc that it should probably be submitted to Avalon Cornerstone at some point. So here's what we did. We i) Took a look at some Avalon code and found that it didn't meet our needs. ii) Wrote code that was in large part based on reading the Avalon code and modifying to our needs iii) Prepared to submit code to Avalon Cornerstone for consideration. Step (iv), actual submission, will happen after we get this release out the door. --Peter -- To unsubscribe, e-mail: <mailto:james-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:james-dev-help@;jakarta.apache.org>
