Reinhard Poetz wrote:
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
Perhaps we don't need a separate jar for internal classes. Marking them with javadoc tags should be enough.
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.
Exactly.
Everything else is part of a block. A block compiles against cocoon-core.jar and cocoon-spi.jar.
.. and also cocoon-api.jar but not because it contains classes that implement API interfaces.
I'm not sure where to put the Flow implementations, XSP and the different templating engines.
Hmm, yes. XSP is currently a block, I say we leave it like that for now. The flow implementation could be part of the core but is perhaps better manageable as a separate unit. The flow Interpreter interface is part of the SPI so by the above reasoning that blocks are SPI implementations this would mean it should be a block. OTOH it is definately different from other blocks. Maybe we need another concept for this. Also because the core is still quite big. I remember some time ago Stefano talked about "aspects" in reference to XSP.
-- Unico
