Reading these discussions after the fact, having Blocks provide only sitemap components seems to make a lot of sense
...not to me - sorry. But maybe I just missed something.
Pier is totally right: we have two different concerns. One is the pipeline services interface and one is the component interface of a block.
But reducing a block just to it's pipeline services basically gives us virtual sitemap components on steroids. What about its dependencies? Well, IIUC one argument in this discussion was that the dependency will be satisfied through a pipeline service - not through a component.
Block A: provides: a pipeline service to transform xml requires: a pipeline service to transform xml with a STX stylesheet
Block B: provides: a pipeline service to transform xml with a STX stylesheet
So block B does not provide the component with hint "stx" but a service that could be anything doing the job satisfying the dependency. Ok.
Now what about the component dependencies? Let's say in order to implement the "transform-via-stx" service block B requires a component of hint "stx". Since the block B has its own component manager and the component "stx" being declared in the block's sitemap all is left is a java class level dependency to the stx implementation. Now the question is - will the block B provide the stx jar? Let's say yes for the moment.
So what if the "transform-via-stx" component needs another component? We could list all the required component in the components section for that very block. ...but still the classes need to be available!
What if the classes are in a different block?
Essentially this means to me: As long as we don't want to ship every block with every component it requires I cannot see how we can get around of having blocks also expose component services.
The idea is that if you have a component that you want to be able to use in several places, you package it in a certain way. Then the improved component handling system that Pier feel the itch to build can found its jar in some repository somwhere, reolve its dependencies and offer a shielded parent classloader with the depndencies you have asked for.
I don't know the exact details about Pier's vison about this, but you can take a look at the kernel in whiteboard for part of it and Maven is also a part of the equation for down�loading and dependency reolution.
Then the responsibility for blocks is to deliver sitemap functionality rather than components. A block declare what components it depend on and the component system takes care of that part for it. It will, at least in my vision, be possible to put Java code and components within the block that only is intended for block internal usage.
--- o0o ---
So the situation rigth now is that Pier have the itch to start integrate improved component handling with classloader shielding ito Cocoon. And I have the itch to start building the sitemap part of the original blocks proposal (actually I have even started on it although nothing is committed yet).
For the time beeing we are going to *assume* that is is separate concerns, although the blocks system will use the component system. In this way we reduce the complexity to a point where we feel comfortable to actually do things, and get experince from that, instead of spending a couple of more years on just discussing them.
In a next step, anyone who feel that it is necessary can integrate the two parts as it was intended originally. My hope is that we don't feel the need, as it IMHO is mixing two different architectural levels and it, according my current state of knowledge, means that we are creating a complexity nightmare for ourselves.
Also letting the block depend on each other in the way that they can export any interface and jar, means that they get a very tight coupling and all kinds of version problems. I can't see that it is scaleable to the level where different organizations develop blocks independently, that users easily can integrate.
--- o0o ---
But this is just my view, if you feel that it is FUD and that is is much easier than I say, it is just to go ahead and propose better ideas and maybe even implement them ;)
/Daniel
