Unico Hommes wrote:
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.
Having a separate cocoon-internal.jar makes block development easier because I wouldn't import it into my classpath.
OK, good point.
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.
Sorry, I don't understand this.
Many sitemap components make use of API interfaces such as Request, Response, etc. Blocks may have usage relation to them but must not have an implements relation to them.
Thanks you, didn't thought about this.
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.
I understand but I'm not sure if having so many different units like "modules", "blocks" and "aspects" helps to make Cocoon more understandable ...
May be a debatable point. I tend to think that with a codebase as large as Cocoon's a lot of stuff can be factored into separate modules before fragmentation starts to get in the way of understandability.
Probably yes.
But with the separation in your proposal we already gain a lot so let's start there.
As so often, evolution instead of revolution seems to be the way to go. After this refactoring we can make a break and look what we already reached and which issues are still unsolved.
I'll prepare a vote after migrating to Subversion.
More thoughts (we have some time until the migration has finished :-)
-- Reinhard
