Stefano Mazzocchi wrote:
If its collaboration then some concrete things need to be considered on the Avalon side and communication channels need to be established. If not - there are migration issues related to ECM/Fortress that can take a back seat in favour of other priorities.
? you are mixing concerns. migrating ECM to Fortress has nothing to do with block support.
Actually it has. There is Avalon and Avalon is supporting the products your using.
Fortress/ECM represent a product family within which there are specific semantic assumptions. Those assumptions need to be drawn out to a more formal specification (and possibly supporting object model) as part of the Avalon development. The Phoenix/Merlin style of component management represents a different set of assumptions. The Fortress/Merlin development has brought that a lot closer, but the end game is the single product that incorporates cleanly and consitently these differences. Reaching the common solution is the migration process I'm talking about. This process is on our roadmap along with a bunch of other topics - hense my note concerning priorities.
In the overall Avalon picture this has to be addressed as we move towards a single Avalon solution - in the shorterm - the Cocoon/Avalon relationship feels kind of mixed.
Cocoon is using the Avalon Framework, ECM and some Excalibur components (some of which are maintained entirely by cocoon committers). Nothing else.
Should we use more? if it makes sense, yes.
Why should we spend months in trying to come up with a solution that makes both Avalon and Cocoon happy for blocks instead of just implementing a design that we already spent almost a year designing?
Lots of reasons, not least are the broadening of the pool of expertise and the potential to leverage experience gained.
Stephen.
--
Stephen J. McConnell mailto:[EMAIL PROTECTED]
