jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Guggisberg <stefan.guggisb...@gmail.com>
Subject Re: On setting component boundaries in Oak
Date Thu, 15 Mar 2012 13:17:35 GMT
On Thu, Mar 15, 2012 at 1:57 PM, Jukka Zitting <jukka.zitting@gmail.com> wrote:
> Hi,
> On Thu, Mar 15, 2012 at 10:19 AM, Stefan Guggisberg
> <stefan.guggisberg@gmail.com> wrote:
>> On Thu, Mar 15, 2012 at 9:07 AM, Angela Schreiber <anchela@adobe.com> wrote:
>>>> The API and protocol bindings on the top are just some examples.
>>> ok... because i am not so sure about a plain WebDAV binding.
>>> imo that one would rather belong on top of the JCR binding.
>>> so, i would rather not have listed here as long as we don't
>>> really plan to build that as it might cause confusion.
> OK, let's drop the WebDAV bit for now from the diagram. As I said,
> it's just an example of what we could do.
>>> well... but this means that the mk implementations that are
>>> currently located in the oak-core module should be moved out
>>> to some different component.
>> agreed, and that's IMO good. we should allow for alternative
>> mk impls (like we did with the jr pm's) but we also should
>> also designate a default impl (sort of a mk api reference impl).
> Yep. I'd like to see that default MK be as simple as possible, ideally
> just an in-memory implementation designed mostly for testing and as a
> reference point for other implementations.

well, i don't understand why you would want to limit it
to a mockup impl. in jr2 we do have a default pm
which is readily useable.

>>> and if we do that i don't really like the idea of having the
>>> MK-API being part of the oak-core module as it requires
>>> MK-implementations to have a dependency to oak-core including
>>> the API... that looks odd to me.
>> same here. the mk api should IMO be a separate individually
>> versioned maven project.
> Note that we can (and should) version the MK API package independently
> on the OSGi package export level. There's no need for the API to
> reside in a separate component for that.

i am not convinced. i would still prefer a separate component.

> Also, since different MK implementations are not meant to be used
> directly without going through oak-core (i.e. there is no deployment
> scenario where oak-core is not included), I don't see a problem with
> having an MK implementation depend on oak-core. Just like a custom
> PersistenceManager implementation needs to depend on jackrabbit-core
> in jr2.

IMO the microkernel is on clearly distinct layer from the oak-core.
there's also the possible scenario of remoting the mk api
(whereas the pm interface was never intended to be remoted).

i'd really prefer to have clear separation on the project layout,
i.e. a mk impl should have its own pom/source tree.


> BR,
> Jukka Zitting

View raw message