Hi, Am 15.03.2012 um 10:19 schrieb Stefan Guggisberg:
> On Thu, Mar 15, 2012 at 9:07 AM, Angela Schreiber <anch...@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. +1 > >> >> 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. +1 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. +1 Regards Felix
