On Thu, Mar 26, 2015 at 3:26 PM, Angela Schreiber <[email protected]> wrote: > Dear Oak Team > > During initial phase of building a new JCR content repository (OAK), > we introduced a new persistence layer API (called MicroKernel API) > originally implemented by the oak-mk module, which since then has > been part of the Oak project. > > In the mean time the overall architecture and design has evolved and > matured and we ended up replacing the original MicroKernel persistence > API by the NodeStore API. Nowadays we only use the MicroKernel API as > wrapper around the NodeStore API but abandoned the original default > implementation. > > Our recommended and maintained Oak setup currently includes the following > options for the persistence layer: > > - Segment Nodestore (aka Tar-MK) > - Document Nodestore (Mongo, Memory, RDB) > > Given these developments in our code base, I came to believe that we no > longer need the original MK implementation.
oak-mk is the reference implementation for the MicroKernel API (oak-mk-api). there exist other MicroKernel API implementations in the oak code base and having a reference implementation and integration tests makes IMO sense for an API with multiple implementations. OTOH since the MicroKernel API has been replaced by the NodeStore API i guess we can remove oak-mk-api, oak-it-mk and all other MicroKernel implementations aswell. so, -1 for removing oak-mk but keeping oak-mk-api +1 for removing oak-mk, oak-mk-api and all MicroKernel implementations cheers stefan > > Since the duplicate persistence API and the mismatch between documentation, > project structure and recommendation used to cause quite some confusion > for people getting started with Oak, and to minimise the maintenance for > the Oak code base on the other hand, I would therefore like to suggest that > we retire the oak-mk module (e.g. moving it to attic) and removing it of > the main oak pom.xml. > > The corresponding JIRA component description should only be adjusted to > reflect this but will continue to exist. > > So, please case your vote for this proposal. > > In case of objection I kindly ask you for some technical description on > why we need to keep oak-mk in the productive oak project and perform > regular releases. > > Thanks and kind regards > Angela > > > >
