Torsten Curdt wrote: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.
My vision is quite simple... How many _COMPONENT_ interfaces we need for Cocoon? Probably 3:
"Generator" "Transformer" "Serializer"
(well, you might have another 2 or 3 of them but do you see the point?)
How many _BLOCK_ interfaces can we have on the other hand?
"ForrestSkin", "WebMailRepository", ....
hundreds.
Then, if each implementation of a block interface is allowed to say "To provide this transformer pipeline service I need the SQL transformer component, the XSLT component and STX component" (all those three simply implement the component "Transformer" Java interface, the problem of dependancy resolution is so easy from both sides:
On the block side, you can completely ignore classloaders and java code, on the component side, you're pretty much sure that the number of component interfaces is not going to be so big and so "volatile" in terms of version numbers (and therefore simplifies the classloading structure).
I mean, the problem right now is not that we have two versions of the "o.a.c.s.Serializer" (Java) interface, but that we _need_ to have in the same Cocoon two versions of "Fop" implementing the _same_precisely_exact_ Java interface...
See what I mean?
Pier
