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?
Cheers,
Andreas
