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