Unblocking Blocks - microstep 1

[Nicola Ken Barozzi]

Starting the blocks walk done with microchanges.

microstep 1: loading of components from blocks
--------------------------------------------------

goal
------

The goal is that if I specify:

<map:blocks>
<map:block name="batik"/>
</map:blocks>

then the sitemap processor will

* look in WEB_INF/blocks for the block jars
* load the batik-block.jar classes
* load the avalon components therein specified in a
cocoon.xconf file in the block jar

Note: All other features like versioning, download (of the block and realted jars), etc will be another microstep.


benefits
----------

No more need to recreate the cocoon.jar after the blocks build. This will make cocoon.jar really indipendent from the blocks.


issues
---------

Small step, but already there are issues.

1. when we will enable versioning, we can have that a block uses
a version of some libraries, and others another.
This mean that we have to load the blocks with different
classloaders, right?

2. Where does the treeprocessor actually create these components? ;-P
It seems that methods are calling methods that are... you get the
picture... I've got not much time to dwelve into that code, but
I looked at the DefaultTreeBuilder.java, but still I'm puzzled.

Can someone please help me and explain how Cocoon uses-handles
the ComponentManager(s), and how the TreeProcessor works?


--
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]