> 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. cheers -- Torsten
signature.asc
Description: OpenPGP digital signature
