Re: followup

[Stephen McConnell <mc...@apache.org>]

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:mcconnell@apache.org