Ok, then I'll be +1. But this raises a point which is for some reason contentious on the list the last few days:
Wouldn't it be better not to do this change on the 2.1.x line? I am assuming that this change would break back-compatibility in some points at least of custom components, etc. and that should be avoided on a released version.
Could someone (Berin?) give an estimate of what the "damage" would be even if we agree it's a good move?
Risk Assessment and Mitigation Strategy:
1) Legacy Components. All legacy components are handled as expected with Fortress as long as the components do not expect ECM itself. In 99% of the cases this is what happens.
2) LogKitManageable. We can create a Lifecycle extension to handle this one, but for future reference, this is best handled via a ServiceManager lookup. Fortress natively uses the LoggerManager, so we get the migration from forced LogKit integration for free.
3) Configuration file format is slightly different. We can create an adaptor to handle the transition (extending the DefaultContainer from Fortress).
4) Components/special selectors that extend ECM directly. There is no real work around for this. Those components have to be altered. To my knowledge, this includes the GeneratorSelector and the SiteMapSelector, and possibly the SiteMap implementation as well as the central Cocoon object. As to third party components, the old ECM libraries would have to be included in a compatibility JAR set.
There is nothing (too my knowlege) that cannot be worked around to provide a seemless integration. What do you all think?
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin