Sylvain Wallez wrote: <snip/>
> >> > >>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? > > > > > > It's here: > http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105766229504616&w=2 > > >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. > > > > > > I think most users don't care about classes at this level: > they just grab a class here or there and start building their > own by overriding public and protected methods. > > And the problem is that these classes often were meant either > as internal and/or helper classes and their contracts were > only thought of within the scope of a particular use, but not > for extension or reuse. > > >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. > > > > > > Mmmh... modularisation is a different concerned, aimed at > making the Cocoon core smaller. But its related I think. Because modularisation will also enable us to provide separate artifacts for compilation dependencies of client code. This way you can tell your users to depend on the API and SPI artifact but not on any others. It would be crystal clear what is considered Cocoon internal and what not. > Optional components introduce > their own API which also needs to be defined and > compatibility ensured. > True. Unico
