Unico Hommes wrote:
Sylvain Wallez wrote:
Unico Hommes wrote:
Reinhard Poetz wrote:
<snip/>
Good idea, but IMO this complements marking the classes, as if you load the full Cocoon in an Eclipse project, completion will show all classes. A notice at the beginning of the javadoc helps in noticing that you use something that's forbidden.I also propose to separate the cocoon.jar into two parts: One that contains all interfaces that can be implemented and all classes that can be used or extended and a second jar that contains the rest which is only used internally. After migrating to Suversion this can be done without breaking the history because this will also require some file moving. IMO this step is necessary to separate our blocks from Cocoon core, isn't it?
I like this too. There could be more than two parts though. There is the API part that contains interfaces used to embed cocoon into a certain environment. The SPI interfaces developers implement to extend the functionality of Cocoon. The different API implementations that we have (CLI, Servlet). And finally the core components.
Can you elaborate on the difference between API and SPI?
This is the way they separate their code into modules at Avalon. I like it because it clearly marks the different functions separate parts of the code play in an application. Interfaces that function as SPI's are for instance the different sitemap component interfaces: Transformer, ProcessingPipeline, Reader, Matcher, etc. An example of an API level interface is for instance Processor and the different environment related interfaces: Request, Context, Environment, etc.
So we have
- cocoon-spi.jar
"Interfaces that function as SPI's are for instance the different sitemap
component interfaces: Transformer, ProcessingPipeline, Reader, Matcher, etc."
- cocoon-api.jar
"An example of an API level interface is for instance Processor and the different
environment related interfaces: Request, Context, Environment, etc."
- cocoon-core.jar Implementations of component interfaces for (re)use
- cocoon-internal.jar everything that should only be used internally
Additionally we can create modules containing the differnet environment implementations:
- servlet-environment.module.jar - commandline-environment.module.jar - ...
A module compiles against cocoon-api.jar.
Everything else is part of a block. A block compiles against cocoon-core.jar and cocoon-spi.jar.
I'm not sure where to put the Flow implementations, XSP and the different templating engines.
Any other ideas/thoughts?
-- Reinhard
