jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jukka Zitting <jukka.zitt...@gmail.com>
Subject Re: On setting component boundaries in Oak
Date Thu, 15 Mar 2012 12:57:44 GMT

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.

>> 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.

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.


Jukka Zitting

View raw message