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 16:11:21 GMT
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


Mime
View raw message