Thanks Jukka, so this means, that the SPI as we had it in Jackrabbit 2.x does no longer exist. And that if we want to continue to support remoting via DavEx (for example) users need to use the (client) code from Jackrabbit.
Regards, Toby On Fri, Nov 29, 2013 at 9:27 PM, Jukka Zitting <[email protected]> wrote: > Hi, > > On Fri, Nov 29, 2013 at 6:05 AM, Tobias Bocanegra <[email protected]> wrote: >> is the SPI meant to be the "PI" for plugins and extensibility? > > Yes. The idea is for Oak extension points to be defined as interfaces > below o.a.j.oak.spi. Also related utility classes are kept there. So > far we have: > > * o.a.j.oak.spi.state - the NodeState model > * o.a.j.oak.spi.commit - commit hooks and the related editors, > validators and observers > * o.a.j.oak.spi.lifecycle - repository initialization > * o.a.j.oak.spi.security - security-related stuff > * o.a.j.oak.spi.query - indexing and query execution > * o.a.j.oak.spi.whiteboard - the whiteboard mechanism > * o.a.j.oak.spi.xml - XML stuff, I'm not sure why this is in SPI > >> all other classes (that are neither api nor utility) should be private >> and implementation detail and probably live in oajo.core.* (assuming >> that core is not exported) or in oajo.spi.impl.* > > We've generally used the packages below o.a.j.oak.plugins for the > implementations. They could usually even be separate maven components, > but so far we've wanted to keep things simple by avoiding too many > small components that complicate deployments and make refactorings and > other cross-codebase work harder. > > PS. Note that some of the plugins have extension points of their own, > so they may also need export some bits. > > BR, > > Jukka Zitting
