Re: BUILD FAILURE: Jackrabbit Oak - Build # 615 - Still Failing
This is issue https://issues.apache.org/jira/browse/INFRA-14804 . I have disabled the Jira post-build step, just to get the builds going. Just to make sure I don't forget, the following settings will be reapplied once the INFRA issue is sorted out: - Jira project key: OAK - Description of test: Jenkins CI failure: https://builds.apache.org/vi ew/J/job/Jackrabbit%20Oak/ - Component name: continuous integration Robert On Tue, 2017-08-08 at 17:13 +, Apache Jenkins Server wrote: > The Apache Jenkins build system has built Jackrabbit Oak (build #615) > > Status: Still Failing > > Check console output at https://builds.apache.org/job/Jackrabbit%20Oa > k/615/ to view the results. > > Changes: > [rombert] OAK-6533 - Adjust test classpath order to reduce number of > error markers in Eclipse > > [rombert] OAK-6532 - Minimise usage of junit-addons > > - remove dependency where it is not used > - add dependency exclusion where needed ( fixes Eclipse-only oak- > lucene > compilation error ) > > [mduerig] OAK-6520: Improve tail compactions resilience when base > state cannot be determined > Fall back to full compaction if the base state is not accessible > because it points to a missing segment > > > > Test results: > All tests passed
BUILD FAILURE: Jackrabbit Oak - Build # 615 - Still Failing
The Apache Jenkins build system has built Jackrabbit Oak (build #615) Status: Still Failing Check console output at https://builds.apache.org/job/Jackrabbit%20Oak/615/ to view the results. Changes: [rombert] OAK-6533 - Adjust test classpath order to reduce number of error markers in Eclipse [rombert] OAK-6532 - Minimise usage of junit-addons - remove dependency where it is not used - add dependency exclusion where needed ( fixes Eclipse-only oak-lucene compilation error ) [mduerig] OAK-6520: Improve tail compactions resilience when base state cannot be determined Fall back to full compaction if the base state is not accessible because it points to a missing segment Test results: All tests passed
BUILD FAILURE: Jackrabbit Oak - Build # 614 - Still Failing
The Apache Jenkins build system has built Jackrabbit Oak (build #614) Status: Still Failing Check console output at https://builds.apache.org/job/Jackrabbit%20Oak/614/ to view the results. Changes: [mduerig] OAK-6522: Implement unit tests for OnlineCompactor Test for IOException during compaction [rombert] OAK-6511 - Switch to official OSGi versioning annotations Changes the annotations from aQute.bnd.annotation to org.osgi.annotation.versioning. As the baselining checks have complained, some packages received a micro version bump. This should be harmless however, import ranges are at most minor, and usually major. In some modules the bndlib dependency was outright removed, as it was not used at all. Test results: All tests passed
BUILD FAILURE: Jackrabbit Oak - Build # 613 - Still Failing
The Apache Jenkins build system has built Jackrabbit Oak (build #613) Status: Still Failing Check console output at https://builds.apache.org/job/Jackrabbit%20Oak/613/ to view the results. Changes: [mduerig] OAK-6372: ListRecord cannot handle more than 16581375 entries Limit lists to 16581375 and fail fast on bigger lists Test results: All tests passed
BUILD FAILURE: Jackrabbit Oak - Build # 612 - Still Failing
The Apache Jenkins build system has built Jackrabbit Oak (build #612) Status: Still Failing Check console output at https://builds.apache.org/job/Jackrabbit%20Oak/612/ to view the results. Changes: [chetanm] Quote the attribute value [chetanm] OAK-6497 - Support old Segment NodeStore setups for oak-run index tooling [chetanm] OAK-6471 - Support adding or updating index definitions via oak-run Updates based on suggestion from Paul Chibulcuteanu -- Fix command -- Clarify that this command requires a matching version of oak-run with target repo [frm] OAK-6528 - Transparently read the two different formats of binary references index Test results: All tests passed
BUILD FAILURE: Jackrabbit Oak - Build # 611 - Still Failing
The Apache Jenkins build system has built Jackrabbit Oak (build #611) Status: Still Failing Check console output at https://builds.apache.org/job/Jackrabbit%20Oak/611/ to view the results. Changes: [mreutegg] OAK-6530: Expose last RGC result via Supplier Test results: All tests passed
BUILD FAILURE: Jackrabbit Oak - Build # 610 - Still Failing
The Apache Jenkins build system has built Jackrabbit Oak (build #610) Status: Still Failing Check console output at https://builds.apache.org/job/Jackrabbit%20Oak/610/ to view the results. Changes: [reschke] fix svn:eol-style Test results: All tests passed
BUILD FAILURE: Jackrabbit Oak - Build # 609 - Still Failing
The Apache Jenkins build system has built Jackrabbit Oak (build #609) Status: Still Failing Check console output at https://builds.apache.org/job/Jackrabbit%20Oak/609/ to view the results. Changes: [mduerig] @trivial: remove assertion that always holds [mduerig] @trivial: static, final [mduerig] @trivial: redundant import, typo Test results: 1 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:126)
BUILD FAILURE: Jackrabbit Oak - Build # 608 - Still Failing
The Apache Jenkins build system has built Jackrabbit Oak (build #608) Status: Still Failing Check console output at https://builds.apache.org/job/Jackrabbit%20Oak/608/ to view the results. Changes: [mduerig] OAK-6452: IllegalStateException: too much data for a segment during oak-upgrade from segment to segment-tar Improved logging Test results: All tests passed
Re: frozen node modifications
> From my point of view, blocking the modification of the history even for > the system that uses Oak as a library, makes its usage far more complicated > in terms of upgrade without any true benefit in terms of security. Note that for one time upgrade work you can still modify the content in version store using the NodeStore API directly. But then you would need to be careful and understand how versioned data is stored Chetan Mehrotra