hi michael maybe that's just the price we have to pay for not designing the scope of oak-core right from the beginning.
if we don't tear it apart, i fear that problems like the one i found with oak.plugins.backup will spread throughout oak-core. kind regards angela On 13/08/14 09:00, "Michael Dürig" <[email protected]> wrote: > >Hi, > >I'm generally in favour of such a move. However, as currently there is >still a lot of fixes from the affected packaged being merged to the 1.0 >branch we should be very careful not to unnecessarily complicate this >process. > >Michael > > > >On 12.8.14 4:54 , Angela Schreiber wrote: >> hi all >> >> i recently had another look at the oak-core module and was thinking >> if it wouldn't be better if we would move the NodeStore implementations >> into separate modules. >> >> to begin with i just tried 2 separate modules: >> >> - oak-ns-document: >> > everything below oak.plugins.document >> >> - oak-ns-segment: >> > everything below oak.plugins.segment >> > segment specific parts of oak.plugins.backup >> >> i found the following issues: >> >> - org.apache.jackrabbit.oak.plugins.cache is not part of the exported >> packages >> - oak.plugins.backup contains both public API and implementations >>without >> separation >> - the following test-classes have a hard dependency on one or more ns >> implementations: >> > KernelNodeStoreCacheTest >> > ClusterPermissionsTest >> > NodeStoreFixture >> to fix those we could need to be able to run the tests with the >> individual nodestore >> modules and move those tests that are just intended to work with a >> particular impl. >> >> such a move would not only prevent us from introducing unintended >> package dependencies but would also reduce the number of dependencies >> present with oak-core. >> >> wdyt? >> >> kind regards >> angela >> >> >> On 12/08/14 16:20, "Michael Dürig" <[email protected]> wrote: >> >>> >>> >>> On 12.8.14 4:08 , Angela Schreiber wrote: >>>> hi claus >>>> >>>>>> And yes, it's confusing. >>>>> .. so I'm not alone here :-) >>>> >>>> no... nobody gets it... in particular as one term is also the >>>> marketing term for the other... just makes the mess a complete mess. >>>> >>>> as far as i am concerned i don't know any good reason for keeping two >>>> APIs for the same thing. IMO we should move the microkernel API to >>>> to the sandbox... the oak code base evolved and it doesn't make sense >>>> to keep things just for nostalgia if they add so much confusion. >>> >>> +1 see https://issues.apache.org/jira/browse/OAK-1327 >>> >>> Michael >>> >>>> >>>> kind regards >>>> angela >>>> >>
