Unico Hommes wrote:
Reinhard Poetz wrote:
<snip/>
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?
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 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?
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
