Antonio Gallardo wrote:
<Steven> But as I said in the SAP R/3 case, this won't solve the problem of the corpulent codebase, and the issues with oversight that comes with its weight. Your efforts in blockifying stuff have already unearthed several issues, and I think we should actively try to keep the core codebase clean & healthy. </Steven>I think it is time to start thinking in a plug-in technology for Cocoon. As Steven pointed. It is inevitable to let people add more and more components (generators, transformers, etc) to Cocoon.
Welcome to the world of Cocoon Blocks.
Thet's a further setp in blocks.What about let people choice what they need? Then they will download only the pieces of code they need. I know this currently can be done manually, but we must find an easy and standard way to deploy the new components. Like a "Lego" toy.
The downloading part is easy, there is already a tool called Ruper that does it with version info etc.
The fact is that now blocks are needed before Cocoon startup, or even worse, at compile-time for the ones using Avalon Components.
If you want to help us on this and have time, it would be great.
The first think to do now IMHO, is to have blocks that don't need to be compiled with Cocoon. In fact Cocoon now includes roles in the cocoon.jar file, so we have to rebuild the cocoon.jar with the infos about the roles needed for the Avalon components in the blocks.
When this is done, all blocks can be added without recompiling Cocoon, and I can add the remote-download feature.
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
