jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tobias Bocanegra <tri...@apache.org>
Subject Re: SPI vs non-SPI
Date Mon, 02 Dec 2013 11:34:48 GMT
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 <jukka.zitting@gmail.com> wrote:
> Hi,
>
> On Fri, Nov 29, 2013 at 6:05 AM, Tobias Bocanegra <tripod@apache.org> 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

Mime
View raw message