Thanks Steve, comments below. ----- Original Message ----- From: "Stephen McConnell" <[EMAIL PROTECTED]>
> 1. James integrity > * building against a cornerstone base that is actually supported > * reducing dependency of Avalon framework by getting rid of the > component interface dependecies (once you switch over to > ServiceManager you are not longer limited to Avalon Components) > 2. James flexibility and independence > * introduce a choice in the James deployment strategy > (including embedded James deployment scenarios) > * elimination of container depedencies (instead of building against > Phoneix jars you would be building against relased jars from Avalon) > * leverage opporuntities arrising from Avalon work on a common container > architecture > 3. Help Avalon rationalize > * James building against Cornerstone and Excalibur components directly > * Immidiate automated feedback from James to Avalon when something > breaks (ourside, yourside, whatever) The 2. points are what I was really looking for and seem like it's worthwhile. As for 3. points (and maybe even 1), I don't think these are very relevant to the James community. I understand the benefit of "eating our own dog food" and using Jakarta and Apache code, but I think James needs to focus on how it wants to eat it, and not try to factor in how it would benefit those other communities. I don't mean this as negative or critical, but with no other library do we seem to consider support, feedback, or latest-build as a consideration for upgrading. Certainly not the CVS integration. As Sam said, we could use Gump against jars instead of direct CVS, and if Avalon didn't branch and doesn't support an older version, well I think that's more Avalon's problem than James (I should stop as Noel already did a better job ranting than I could). Serge Knystautas Loki Technologies http://www.lokitech.com/ -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
