Noel J. Bergman wrote: > > Rather than port James to a new set of "Foo" interfaces, > > why not implement Avalon's "Serviceable/Configurable/etc" > > interfaces to your own "Foo" environment, enabling you to > > port all apps. conforming to the Avalon interfaces? > > Because the goal would be container independence, not another > container > hosting Avalon-specific apps. :-) And James could certainly > benefit from > such.
No disagreement in principle. Refactoring the bulk of James into POJOs would be a good thing. Just not good enough on technical merit alone. I don't see a 'killer' reason. Without one I cannot see why effort should be diverted from enhancing James up to v3 as previously envisaged. I would be pro-change for killer reason such as: - If there was a definative statement that the Avalon approach is about to be deprecated, flip its mortal coil, or whatever. But that isn't the current state of play as I understand it. Or am I missing something? - If the effort of the infrastructure changes in support of the v3 enhancements in the current environment is similar to the of moving to a new, POJO based, infrastructure for v3. - If the use of Avalon is: * a constraint on the functionality we wish to add to James * a major disincentive to user adoption * a major disincentive to developer contributions Personally, I do not see that any of the above statements apply right now. Some may do in the future. Do others have their own killer reasons right now? -- Steve --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
