[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-07 16:46:34
Message-ID: 439711EA.8020804 () apache ! org
[Download RAW message or body]

Marc Portier wrote:
> 
> Reinhard Poetz wrote:
> 
>>Today, Jorg and I had a long chat about this. In short, we failed to
>>find a solution that works with Maven 2 as it is today. The problem is
>>that Cocoon block requirements have a different purpose than Maven 2
>>dependencies. Cocoon block requirements desribe what a block needs to
>>run while Maven 2 dependencies describe what a project needs to compile.
>>Additionally we want to describe our dependencies as contracts and not
>>as direct dependencies to a JAR.
>>
> 
> 
> how is that different?

well, in Cocoon we don't have "direct" dependencies between blocks. A Cocoon 
block only requires other blocks that implement a certain contract. Have a look 
at this example:

<block xmlns="http://apache.org/cocoon/blocks/cob/1.0"
  id="http://cocoon.apache.org/blocks/anyblock/1.0">

  <requirements>
   <requires
     interface="http://cocoon.apache.org/contracts/portal/1.0"
     name="portal"
     default="http://cocoon.apache.org/blocks/portal/1.0.2"
   />
  </requirements>

</block>

Here the block "http://cocoon.apache.org/blocks/anyblock/1.0" requires a block 
that implements the contract "http://cocoon.apache.org/contract/portal/1.0".

One block that obiously implements this contract is 
"http://cocoon.apache.org/blocks/portal/1.0.2".

Compare this with a Maven project descriptor. There we say which *concrete" 
dependencies (jars, blocks) one project has. In this special case this is a 
block dependency.

 > I would guess this just means your 'contract' is available in a separate
 > jar/artifact from your implementation?

I'm not sure if I understand completly what you're asking/suggesting here. Do 
you mean that we should make the contract a JAR dependency too?

 > is that a constraint that is hard to keep up with?


I'm not sure. I have to think more about it. In any case, having the contracts 
as JAR dependencies is an interesting thought!

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