Stefano Mazzocchi wrote:
On Thursday, Oct 9, 2003, at 17:15 Europe/Rome, Ryan Hoegg wrote:
Rather than have cocoon blocks extend avalon blocks, I think cocoon blocks could use avalon blocks.
Ok, I see your point.
Instead of having a /COB-INF and a /BLOCK-inf, perhaps we include avalon blocks in /COB-INF/lib and delegate their deployment to the avalon container. This could even allow cocoon blocks to provide avalon blocks to the container, as well as require them.
I would not know how to do this! I'm not scared by merlin, I'm scared about the million little details that cocoon assumes on top of ECM and that are now considered deprecated by the "modern" containers.
The million little details that cocoon assumes on top of ECM is also the thing that scares me the most.
if Fortress was there, admittedly, things would be easier... but then again, lots of talks, but nobody is able, wants or has time/energy/braveness to do the migration.
Is there someone who provide the breakdown of what Cocoon is doing over and above ECM? However things roll out - one of the biggest obsticles I see is that we need to move away from ECM/Fortress extension and to a solution where Cocoon does not need to access container APIs. With that information the Avalon crowd can address how to addres these requirements in a way that makes the concern indpendent of the container implementaiton.
It may help to distinguish between different types of dependencies:
1. Block dependency. As described in http://wiki.cocoondev.org/Wiki.jsp?page=BlocksDefinition and specified in http://wiki.cocoondev.org/Wiki.jsp?page=BlocksWiring . What we (I think) have been talking about in several threads.
2a. Avalon dependency by block. This would be some avalon service/component that is required by the block, and would be explicitly declared. An example might be a Transformer or the Flow engine.
2b. Avalon dependency by avalon block/component/service. This would be some avalon service that is required by an avalon service or block that is included with the cocoon block. For example, I have a UserManager service that depends on a UserRepository service, which could be implemented by an OJBUserRepository. If the cocoon block included the UserManager block, it might ask the Parent Component Manager for a UserManager, and might be provided with the OJBUserRepository.
I fear the complexity of such a move.
Break the complexity down into managable chunks.
1. migrate from Component to Object 2. migrate from roles files to meta
Just achiving the above opens up a much broader spectrum of possibilities and the question become much more concrete and substantive (from both sides of the equation). We have been discussing this over on Avalon land - subjects such as transition vehicles, migration tools, etc. these are way up on the agenda.
Steve.
--
Stephen J. McConnell mailto:[EMAIL PROTECTED]
