The Apache Jenkins build system has built Jackrabbit Oak (build #783)
Status: Failure
Check console output at https://builds.apache.org/job/Jackrabbit%20Oak/783/ to
view the results.
Changes:
[stillalex] OAK-6703 Refactor oak.namepath package
Test results:
1 tests failed.
FAILED:
On 21/09/2017 05:48, Chetan Mehrotra wrote:
> I would like to backport OAK-6637
+1 (you already did :) )
D.
OAK-6635 is now resolved.
Chetan Mehrotra
On Fri, Sep 22, 2017 at 3:25 PM, Davide Giannella wrote:
> Hello team,
>
> I'm planning to cut Oak on Monday 25th.
>
> There's however a blocker which will block the release if not resolved
> or re-scheduled:
Hello team,
I'm planning to cut Oak on Monday 25th.
There's however a blocker which will block the release if not resolved
or re-scheduled: https://issues.apache.org/jira/browse/OAK-6635
If there are any objections please let me know. Otherwise I will
re-schedule any non-resolved and
On Fri, Sep 22, 2017 at 9:14 AM, Tomek Rekawek
wrote:
> ...Bertrand - could you clarify if the jails should share some data with the
> “main” repository (which would
> make it more difficult, as Robert and Michael wrote) or the self-contained
> approach is ok?...
Hello Robert & Michael,
> On 22 Sep 2017, at 08:31, Robert Munteanu wrote:
>>
>> this seems like an opposite of the composite node store - rather than
>> combining multiple repositories together, we’re trying to split one
>> repository into many jails. Maybe I’m too
Hi,
I agree that on the NodeStore level this is probably easy enough.
However mind you that the JCR semantics demand for *a lot* of shared
global state, all of which is implement on top of the NodeStore. It is
this global state that complicated the composite store implementation
and in fact
Hi Tomek,
On Fri, 2017-09-22 at 05:03 +, Tomek Rekawek wrote:
> Hello Bertrand,
>
> this seems like an opposite of the composite node store - rather than
> combining multiple repositories together, we’re trying to split one
> repository into many jails. Maybe I’m too optimistic, but I think