Andreas Hochsteger wrote:
Reinhard Poetz schrieb:
Andreas Hochsteger wrote:
Ah, very insightful!
This would be a good start.
But with this interim solutions we have to be aware of the fact, that
the block has to define all potential XSL:FO implementations as
optional dependencies. This might not be the possible in every case.
Think about choosing some commercial XSL:FO implementation to be used
for all blocks wich depend on the XSL:FO contract or providing your
own implementation for another contract.
Why is just adding the block dependency that I *want* to use not
enough? The only issue that I can think of is that it doesn't prevent
the developer from using implementation internal classes. Right?
For blocks and deployments which are fully under the control of the
developer this is right.
The point I'm trying to make has something to do with SoC and more
specific with the role of the deployer:
The block A, which uses an XSL:FO processor should IMHO only depend on
the XSL:FO contract (API) since it can not assume which concrete
implementation will be used in a certain deployment scenario.
An application developer which uses block A (developed by somebody else)
now wants to use a certain XSL:FO implementation for his application. It
would not make sense that this application developer has to modify the
pom of block A just to put his prefered XSL:FO implementation to the
list of dependencies.
In short:
Isn't it enough to let the pom of block A just depend on the XSL:FO
contract?
That's one of the differnces between block requirements and Maven2 dependencies.
Maven2 dependencies are concrete implementations and block requirement always
point to a contract which have to be implemented by a block.
What we _could_ do is having real artifacts for our contracts and not just URIs.
Well, I think that future experiments with a working deployment system will
help us to understand better what we really need. For now I will implement it
the way it was designed a long time ago (based on the block.xml and it's IMO
well-designed features) and we can use this as starting point for further
discussions.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
