cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <reinh...@apache.org>
Subject Re: Cocoon 2.2 - Build and deployment with Maven2
Date Fri, 16 Dec 2005 07:17:51 GMT
Andreas Hochsteger wrote:
> 
> 
> Jorg Heymans schrieb:
> 
>>
>>
>> Reinhard Poetz wrote:
>>
>>>
>>> We also discussed the structure of projects as proposed by Jorg some 
>>> time ago
>>> (http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=113102875010469&w=2).
>>>
>>> /my-block
>>>      pom.xml
>>>      /api
>>>         pom.xml
>>>      /impl
>>>         pom.xml
>>>      /samples
>>>         pom.xml
>>>
>>> The (usual) dependencies are:
>>>
>>>  - impl depends on api (normal JAR dependency)
>>>  - the sample block depends on the impl block
>>>
>>> Out of this we will get two blocks:
>>>
>>>  - my-block-block
>>
>>             ^^^^^^^^
>>
>> Don't you mean my-block-impl-block ?
>>
>> The main thing here is that we feel that api is not a "real" block (ie 
>> it won't have a block descriptor).
>>
>> impl is the thing people can actually use when building webapps.
>>
>> samples is just an "example" of how the impl block can be used in a 
>> webapp ie it demonstrates the blocks' capabilities. It is a real block 
>> on its own and has a block dependency (not a normal jar dependency) on 
>> impl.
> 
> 
> But how would it be possible to say that the samples block depends on 
> any implementation which implements a certain API, like the roles are 
> used in Cocoon today?
> For example, my-block-samples-block needs an XSL:FO processor but does 
> not depend on a concrete implementation (e.g. Xalan).
> 
> Taken your example then my-block-samples-block would depend on 
> my-block-block (assuming it would contain the API) - or am I missing 
> something?

yes :-)

Splitting up the directory structure in our code repository into api, impl and 
samples has the purpose of making it easier for us the get three artifacts out 
of one block:

  - two block jars (the block itself, samples)
  - one jar that is not a block (the API jar)

and to make IDE integration and the development of the three mini-projects simpler.

If my-block-samples-block needs a XSL:FO processor the block.xml has following 
notation:

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

   <requirements>
     <requires
       interface="http://cocoon.apache.org/contract/xsl-fo/1.0"
       name="xsl-fo"
       default="http://cocoon.apache.org/blocks/fop/1.0.2"
     />
     <requires
      interface="http://cocoon.apache.org/contract/my-block/2.0"
      name="my-block"
      default="http://cocoon.apache.org/blocks/my-block/2.7.14"
     />
   </requirements>

</block>

In /my-block/samples/pom.xml you will find following entries:

<dependencies>
   <dependency>
     <groupId>org.apache.cocoon.fop</groupId>
     <artifactId>fop</artifactId>
     <version>1.0.2</version>
   </dependency>
   <dependency>
     <groupId>org.apache.cocoon.my-block</groupId>
     <artifactId>my-block</artifactId>
     <version>2.7.14</version>
   </dependency>
</dependencies>

(I'm not sure about the details, e.g. what's the correct name for all the IDs 
... but I will hopefully get more insight during the development of the deployer)

As you can see here, we have the problem that block.xml and pom.xml describe 
similar things and should be unified but ATM I don't see a good way for it 
except that Maven poms give us the possibility to add properties to the 
dependencies. As this is not possible now I will start with using block.xml and 
when it's possible we can think how we can merge it with pom.xml.

-- 
Reinhard Pötz           Independent Consultant, Trainer & (IT)-Coach 

{Software Engineering, Open Source, Web Applications, Apache Cocoon}

                                        web(log): http://www.poetz.cc
--------------------------------------------------------------------

Mime
View raw message