[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:       Reinhard Poetz <reinhard () apache ! org>
Date:       2005-12-18 12:51:06
Message-ID: 43A55B3A.8040104 () apache ! org
[Download RAW message or body]

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
--------------------------------------------------------------------

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