[prev in list] [next in list] [prev in thread] [next in thread] 

List:       xml-cocoon-dev
Subject:    Re: Cocoon 2.2 - Build and deployment with Maven2
From:       Andreas Hochsteger <e9625392 () student ! tuwien ! ac ! at>
Date:       2005-12-17 16:33:54
Message-ID: 43A43DF2.3030009 () student ! tuwien ! ac ! at
[Download RAW message or body]


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
[prev in list] [next in list] [prev in thread] [next in thread]