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?

Jorg

Andreas