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