Leo, As usual, an interesting RT. This is also something that I am *VERY* interested in. The current lack of cohesion between Avalon projects is something that really bugs me, so I think that a TCK could help to bring them all together. Therefore, I liked the LCD approach; but I am not in favor of leaving it there. In my opinion, if a component works in all of the current containers (ecm/fortress/pheonix/merlin) then the component should be Avalon Framework TCK 1.0 compatible. Avalon Framework TCK 1.1 could include whatever formalities have been introduced for Merlin.
Jonathan Hawkes > * We could say that compatibility is defined by the the least common > denominator of the current ecm/fortress/phoenix/merlin featureset. That > LCD is definable, testable, and hence not subject to much debate (if > there's debate, you can write a test to show compatibility or > incompatibility). It rules out any lifestyle but singleton, marker > interfaces, any combination of Loggable/LogEnabled or > Composable/Servicable, Executable, Re***, making avalon-meta part of the > avalon-framework contract, and many other things. > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
