The vote results are as follows:
+1 Marcel Reutegger
+1 Michael Dürig
+1 Thomas Mueller ("for moving oak-mk and oak-mk-api to attic and
removing all other MicroKernel implementations")
+1 Stefan Guggisberg ("for removing oak-mk, oak-mk-api and all MicroKernel
implementations")
-1 Stefan Guggisberg ("for removing oak-mk but keeping oak-mk-api")
+1 Angela Schreiber
Not sure, what the correct procedure is now. Shall I cancel
this vote and start a new one for
"moving oak-mk and oak-mk-api to attic and removing all other
MicroKernel implementations"
? Or should I rather extend this very vote to make sure everyone
would be comfortable with the extended scope as proposed by Stefan?
Please advise
Regards
Angela
On 26/03/15 15:26, "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.
>
>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
>
>
>
>
