cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Hochsteger <e9625...@student.tuwien.ac.at>
Subject Re: Cocoon 2.2 - Build and deployment with Maven2
Date Sat, 17 Dec 2005 09:41:59 GMT
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.

Andreas

Reinhard Poetz schrieb:
> 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.
> 

Mime
View raw message