jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Meschberger <fmesc...@adobe.com>
Subject Re: On setting component boundaries in Oak
Date Thu, 15 Mar 2012 11:02:40 GMT

Am 15.03.2012 um 10:19 schrieb Stefan Guggisberg:

> On Thu, Mar 15, 2012 at 9:07 AM, Angela Schreiber <anchela@adobe.com> wrote:
>>> Since according to this overall architecture there's a 1-to-1
>>> connection between these two APIs and the implementation in between
>>> and since they together form the core of a repository instance, I
>>> think we should (at least for now) keep them together the a single
>>> "oak-core" component, as shown in this diagram:
>>>     http://people.apache.org/~jukka/2012/oak-components2.png
>> 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).
>> 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.


>> so, imo we should rather keep oak-api (aka spi) and the
>> mk api/impl separate. that would lead us to start with 3
>> components that identify the layers and make the dependencies
>> very clear.
> agreed, except that i would separate the mk api from the mk impls.


This would make it easy to implement a test kit for MK implementations.

>>> The "oak-jcr" component that I also identified in the above diagram
>>> would only contain the code needed to adapt between the Oak API and
>>> the higher level JCR API.
>> makes sense. and again: oak-jcr needs to have a dependency
>> to the oak-api but should not deal with MK... having a clear
>> separation dependency-wise would be favorable here IMO.
> +1, otherwise untangling the components at a later stage would
> be unnecessary hard.


View raw message