Daniel Fagerstrom skrev:
Reinhard Poetz skrev:
...
According to the pom.xml of the blocks framework, it depends on
cocoon-core. I'm not sure but if we consider cocoon-core being a block
too, we get a circular dependency, don't we?
Yes it becomes circular, OTH I don't want any special purpose component
configurations during the bootstrap of the blocks system. The workaround
for now should IMO be to have cocoon-core at the initial classpath
(WEB-INF/lib) and have a fake core block that only contains the
configuration file, but no classes.
I checked in an example of this, if you agree about the solution, you
could add a cocoon-core-components (e.g.) block that just contain the
configuration files, that can be used by the deployer.
I also integrated your code for adding the blocks to the class loader,
into the BlocksManager. No handling of jars yet, and not much testing.
Feel free to improve it ;)
Now everything should be in place for making it possible to actually
execute the deployed blocks.
/Daniel
