cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <reinh...@apache.org>
Subject Re: [Vote] Marking internal classes
Date Mon, 19 Jul 2004 12:36:00 GMT
Unico Hommes wrote:

> Sylvain Wallez wrote:
>
>> 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?
>
> 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

Mime
View raw message