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?
-- Reinhard
