[Oak origin/trunk] Apache Jackrabbit Oak matrix - Build # 1250 - Still Failing

[Apache Jenkins Server]

The Apache Jenkins build system has built Apache Jackrabbit Oak matrix (build 
#1250)

Status: Still Failing

Check console output at 
https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/1250/ to view 
the results.

Changes:
[thomasm] OAK-5018 Warn traversal queries: false positives

[chetanm] OAK-5026 - Enable default memory mapping for segment mode in oak-run

[mreutegg] OAK-5027: Test utils for commonly used functionality

[mreutegg] OAK-3018: Use batch-update in backgroundWrite

 

Test results:
2 tests failed.
FAILED:  org.apache.jackrabbit.oak.segment.standby.StandbyTestIT.testSyncLoop

Error Message:
expected: org.apache.jackrabbit.oak.segment.SegmentNodeState<{ checkpoints = { 
... }, root = { ... } }> but was: 
org.apache.jackrabbit.oak.segment.SegmentNodeState<{ checkpoints = { ... }, 
root = { ... } }>

Stack Trace:
java.lang.AssertionError: expected: 
org.apache.jackrabbit.oak.segment.SegmentNodeState<{ checkpoints = { ... }, 
root = { ... } }> but was: org.apache.jackrabbit.oak.segment.SegmentNodeState<{ 
checkpoints = { ... }, root = { ... } }>
at 
org.apache.jackrabbit.oak.segment.standby.StandbyTestIT.testSyncLoop(StandbyTestIT.java:122)


FAILED:  org.apache.jackrabbit.oak.segment.standby.StandbyTestIT.testSyncLoop

Error Message:
expected: org.apache.jackrabbit.oak.segment.SegmentNodeState<{ checkpoints = { 
... }, root = { ... } }> but was: 
org.apache.jackrabbit.oak.segment.SegmentNodeState<{ checkpoints = { ... }, 
root = { ... } }>

Stack Trace:
java.lang.AssertionError: expected: 
org.apache.jackrabbit.oak.segment.SegmentNodeState<{ checkpoints = { ... }, 
root = { ... } }> but was: org.apache.jackrabbit.oak.segment.SegmentNodeState<{ 
checkpoints = { ... }, root = { ... } }>
at 
org.apache.jackrabbit.oak.segment.standby.StandbyTestIT.testSyncLoop(StandbyTestIT.java:122)

Re: segment-tar depending on oak-core

[Francesco Mari]

Hi

2016-10-27 19:08 GMT+02:00 Alexander Klimetschek :
> Maybe looking at this step by step would help.

The oak-segment-tar bundle was supposed to be the first step.

>For example, start with the nodestore implementations and extract everything 
>into separate modules that is necessary for this - i.e. an oak-store-api along 
>with the impls. But keep other apis in oak-core in that first step, to limit 
>the effort. (And try not renaming the API packages, as well as keeping them 
>backwards compatible, i.e. no major version bump, if possible).

This didn't happen because of lack of consensus. See my previous
answer to Michael Marth.

>See how that works out and if positive, continue with more.

The reaction to the modularization effort was not positive, so
oak-segment-tar backed up.

>
> Cheers,
> Alex
>
> Am 27. Okt. 2016, 03:48 -0700 schrieb Francesco Mari 
> :
> Something did happen: the first NodeStore implementation living in its
> own module was oak-segment-tar. We just decided to go back to the old
> model exactly because we didn't reach consensus about modularizing its
> upstream and downstream dependencies.
>
> 2016-10-27 12:22 GMT+02:00 Michael Marth :
> fwiw: last year a concrete proposal was made that seemed to have consensus
>
> “Move NodeStore implementations into their own modules"
> http://markmail.org/message/6ylxk4twdi2lzfdz
>
> Agree that nothing happened - but I believe that this move might again find 
> consenus
>
>
>
> On 27/10/16 10:49, "Francesco Mari"  wrote:
>
> We keep having this conversation regularly but nothing ever changes.
> As much as I would like to push the modularization effort forward, I
> recognize that the majority of the team is either not in favour or
> openly against it. I don't want to disrupt the way most of us are used
> to work. Michael Dürig already provided an extensive list of what we
> will be missing if we keep writing software the way we do, so I'm not
> going to repeat it. The most sensible thing to do is, in my humble
> opinion, accept the decision of the majority.
>
> 2016-10-27 11:05 GMT+02:00 Davide Giannella :
> On 27/10/2016 08:53, Michael Dürig wrote:
>
> +1.
>
> It would also help re. backporting, continuous integration, releasing,
> testing, longevity, code reuse, maintainability, reducing technical
> debt, deploying, stability, etc, etc...
>
> While I can agree on the above, and the fact that now we have
> https://issues.apache.org/jira/browse/OAK-5007 in place, just for the
> sake or argument I would say that if we want to have any part of Oak
> with an independent release cycle we need to
>
> Have proper API packages that abstract things. Specially from oak-core
>
> As soon as we introduce a separate release cycle for a single module we
> have to look at a wider picture. What other modules are affected?
>
> Taking the example of segment-tar we saw that we need
>
> - oak-core-api (name can be changed)
> - independent releases of the oak tools: oak-run, oak-upgrade, ...
> - independent release cycle for parent/pom.xml
> - anything I'm missing?
>
> So if we want to go down that route than we have to do it properly and
> for good. Not half-way.
>
> Davide
>
>