Berin Loritsch wrote, On 02/09/2003 19.11:
Geoff Howard wrote:...
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?
I think that this will bring Cocoon one step ahead by removing some wrong dependencies it has with the implementation (ECM) and changing them with new more standard and future-compatible contracts.
The "change" is not insignificant, but the "damage" seems very slight for non-core Cocoon developers.
+1 for 2.2 switching to Fortress
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------