cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Unico Hommes <un...@hippo.nl>
Subject Re: [Vote] Marking internal classes
Date Sun, 18 Jul 2004 13:43:09 GMT
Reinhard Poetz wrote:

> Guido Casper wrote:
>
>> Guido Casper wrote:
>>
>>> Vadim Gritsenko wrote:
>>>
>>>> In all other situations, Carsten is right - this might cause 
>>>> backward incompatibility. This is important for user-facing 
>>>> classes. Should we start marking classes as internal, like 
>>>> "<b>INTERNAL!!!</b>" in javadoc or some such?
>>>
>>>
>>>
>>>
>>> What about introducing @cocoon.usage tags I proposed a while ago like:
>>> @cocoon.usage published
>>>
>>> or:
>>> @cocoon.usage flowscript
>>>
>>> etc.
>>>
>>> This might someday also be used to generate separate Javadocs for 
>>> different APIs.
>>
>>
>>
>> Hm, noone (but me :-) seems to like the idea.
>
>
>
> ;-)
>
>> So maybe it's a good idea to first have a quick vote about whether to 
>> mark internal classes as such or to mark "published 
>> classes/interfaces" as such (and then decide how to mark them).
>
>
>
> +1
>
> 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.

--
Unico

Mime
View raw message