Steve,
> It is an unfortunate situation, but I think the path that will cause the > least pain now and in the future is to bite the bullet and do it. There > aren't too many mailets that use a ComponentManager / ServiceManager and > for those the code change is trivial. But that's exactly the question - do what? Replace ComponentManager with ServiceManager? Is this our permanent solution (very -1)? If not, how do we present it to our user base? When do we expect to have a permanent solution? > Let's not get into forked Cornerstone or being tied to prehistoric > releases of Avalon packages, both of which will just lead to more and > more compatibility problems. James needs to be able to move up to newer > releases of these packages as easily as possible. Absolutely agree. > As far as backwards compatibility is concerned, this is partially blown > already with the enabled flag required in config files so existing > config files will no longer work. Admittedly this is much easier to > fix. There is a huge difference here. Basically we can (and should) write some simple XML transform code to change the config file as necessary. Even if we don't do this, any administrator can be instructed to do minor adjustments to their config file. Changing APIs is an entirely different order of magnitude. --Peter -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
