Mailing-List: contact oak-dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: oak-dev@jackrabbit.apache.org
Received-SPF: pass (nike.apache.org: domain of stefan.guggisberg@gmail.com
 designates 74.125.83.42 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAOFYJNan+ud6wp_2XgkWD7D5FKr02HF1BviSiT_bZ4-KVd4T-A@mail.gmail.com>
References: 
 <CAOFYJNZhxUD5RSVkqO+sxeSQmKQ6qmX-YS0jBLbTs=05J0CNqA@mail.gmail.com>
	<4F5A025B.8050600@adobe.com>
	<CAFYk8N=NuNV6SiUi34tVeV6v-PRyv2pxaUkgk+zyX3Ftfj8c-g@mail.gmail.com>
	<CAOFYJNaidMoQZ6Ck=dzL8M9K+QHZ4OE0DeLOkMEsXOp-xhUUMQ@mail.gmail.com>
	<CAOFYJNY3pkV-CBLidmBhNWNxBtZ7st6y8wua79Lv8oX7Nm8BOg@mail.gmail.com>
	<4F61A34C.80501@adobe.com>
	<CAFYk8NkguU_UCqu1y5gTrQGBXP+oVE=0uD6e4DGDSkrTaxyJyQ@mail.gmail.com>
	<CAOFYJNan+ud6wp_2XgkWD7D5FKr02HF1BviSiT_bZ4-KVd4T-A@mail.gmail.com>
Date: Thu, 15 Mar 2012 14:17:35 +0100
Message-ID: 
 <CAFYk8N=bG0W-rRpPAJWb+F_dBwbe3Z1+Vw22FneFV+k5rg84Yw@mail.gmail.com>
Subject: Re: On setting component boundaries in Oak
From: Stefan Guggisberg <stefan.guggisberg@gmail.com>
To: oak-dev@jackrabbit.apache.org
Content-Type: text/plain; charset=ISO-8859-1

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.

cheers
stefan

>
> BR,
>
> Jukka Zitting