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.
