Sylvain Wallez wrote: > > Carsten Ziegeler wrote: > > <snip/> > > >So, I'm in favour of deprecating this in 2.1 now and > removing it in 2.2. > > > > > > While I'm more than ok with simplifying stuff, we have to > take great care of backwards incompatible changes. > > Our version-naming scheme "x.y.z" states that compatibility > should be ensured between different "y" versions. This has > not been exactly the case between 2.0 and 2.1, and I fear > that the more radical changes that occur between 2.1 and 2.2 > will lead to more incompatibilities. > > So the question is: aren't we moving towards a 3.0 release? > > Or shouldn't we make more effort at defining Cocoon's public > and private APIs? I made a proposal a while a go for this, > based on javadoc attributes, but never investigated it further. > > Should we make this a high priority task, so that we can > distinguish what we consider to be Cocoon's internal from the > officially supported API? >
Yes! IMO this should be very high on the priority list. I was planning to write a proposal for that. I missed your previous proposal. Do you have a pointer? I was thinking that we could make the seperation across API, SPI, and implementations. Similar to the way they have been doing that in Avalon. API being the interfaces clients can use to embed Cocoon into their environment. So that would for instance be the Processor and Environment related interfaces. SPI would include the sitemap component interfaces. The stuff users implement to extend Cocoon's functionality. And then provide two separate implementations of the public API: servlet and cli. This could go hand in hand with the proposed modularisation of the code. There's probably more modularisation neccessary. For instance, what I'd really like to see is something like XSP to be optional as well as other stuff I am not sure would fit into a block. Thoughts? Unico
