On Wed, Nov 20, 2013 at 11:41 PM, Jukka Zitting wrote:
> Yes, sounds like a good candidate. The only additional bit we'd need
> is a timestamp that allows indexers on other cluster nodes to
> automatically resume processing if an active indexing task dies for
> whatever reason without a chance to
Hi Marcel,
Probably below code can be simplified using the Lists.partition(list,size) [1]
> -// update if this is the last path or
> -// revision is not equal to last revision
> -if (i + 1 >= paths.size() || size == ids.size()) {
> +// call update i
Build Update for apache/jackrabbit-oak
-
Build: #2843
Status: Fixed
Duration: 1690 seconds
Commit: 3fa2567bf51350b765d294bc18558c5311065bcc (trunk)
Author: Jukka Zitting
Message: OAK-593: Segment-based MK
Simplify SegmentNodeStoreBranch by dropping the obsolet
Build Update for apache/jackrabbit-oak
-
Build: #2841
Status: Fixed
Duration: 2066 seconds
Commit: 426fd63c7cc4347c18699babd8cf9034a2b8c76c (trunk)
Author: Jukka Zitting
Message: OAK-924: Optimize namespace lookups
fix typo
git-svn-id: https://svn.apache.org/
Build Update for apache/jackrabbit-oak
-
Build: #2842
Status: Fixed
Duration: 1665 seconds
Commit: d5ececa007a67af2228476539726c5d3980fd112 (trunk)
Author: Jukka Zitting
Message: OAK-659: Move purge logic for transient changes below the NodeBuilder
interface
The Buildbot has detected a restored build on builder oak-trunk while building
ASF Buildbot.
Full details are available at:
http://ci.apache.org/builders/oak-trunk/builds/3876
Buildbot URL: http://ci.apache.org/
Buildslave for this Build: osiris_ubuntu
Build Reason: scheduler
Build Source Stam
Build Update for apache/jackrabbit-oak
-
Build: #2840
Status: Broken
Duration: 1049 seconds
Commit: 7b3d8a365df8e5d59a5c71e749b9b5f76b82e4d2 (trunk)
Author: Jukka Zitting
Message: OAK-924: Optimize namespace lookups
Optimize the access of prefix information in
Hi,
On Mon, Dec 2, 2013 at 6:01 PM, wrote:
> Blamelist: jukka
Sorry, typo. Fixed in followup commit.
BR,
Jukka Zitting
The Buildbot has detected a new failure on builder oak-trunk while building ASF
Buildbot.
Full details are available at:
http://ci.apache.org/builders/oak-trunk/builds/3875
Buildbot URL: http://ci.apache.org/
Buildslave for this Build: osiris_ubuntu
Build Reason: scheduler
Build Source Stamp:
On Mon, Dec 2, 2013 at 5:06 PM, Angela Schreiber wrote:
> just one more addition:
>
> IMHO it was fairly straight forward to implement the server side
> part of the jcr-remoting based on OAK. that would fit pretty much what
> was always listed as 'native' implementation in the jackrabbit
> documen
Build Update for apache/jackrabbit-oak
-
Build: #2832
Status: Fixed
Duration: 1947 seconds
Commit: 881694085d71e949710e9654582498868362d358 (trunk)
Author: Angela Schreiber
Message: OAK-1201 : Implement jackrabbit api specific descriptors
git-svn-id: https://s
Build Update for apache/jackrabbit-oak
-
Build: #2831
Status: Fixed
Duration: 2315 seconds
Commit: c3b8c604c0ecf19a524fb598e8f843064d61a007 (trunk)
Author: Jukka Zitting
Message: OAK-1249: Fine-grained locking in SegmentMK commits
Stick with a global lock for
just one more addition:
IMHO it was fairly straight forward to implement the server side
part of the jcr-remoting based on OAK. that would fit pretty much what
was always listed as 'native' implementation in the jackrabbit
documentation (and which was always marked with a dotted lined).
that was f
The Buildbot has detected a restored build on builder oak-trunk while building
ASF Buildbot.
Full details are available at:
http://ci.apache.org/builders/oak-trunk/builds/3865
Buildbot URL: http://ci.apache.org/
Buildslave for this Build: osiris_ubuntu
Build Reason: scheduler
Build Source Stam
The Buildbot has detected a new failure on builder oak-trunk while building ASF
Buildbot.
Full details are available at:
http://ci.apache.org/builders/oak-trunk/builds/3862
Buildbot URL: http://ci.apache.org/
Buildslave for this Build: osiris_ubuntu
Build Reason: scheduler
Build Source Stamp:
Build Update for apache/jackrabbit-oak
-
Build: #2827
Status: Broken
Duration: 324 seconds
Commit: 8e255ea5a683d896b090cd81af9aba288ec394b7 (trunk)
Author: Thomas Mueller
Message: OAK-98 Source code formatting, code conventions, Javadocs, simple
refactoring
g
On Mon, Dec 2, 2013 at 3:42 PM, Marcel Reutegger wrote:
> ...it may make sense to rename it to something more generic, since
> the majority of code is agnostic of the underlying storage
I'm curious now, is DocumentStore yet another way of creating a custom
storage backend for Oak, besides Nod
Hi,
> a) package structure: right now the existing implementations live in
> org.apache.jackrabbit.oak.plugins.mongomk -- shouldn't we use separate
> packages?
the package name is inspired by the primary backend implementation, which
is MongoDB. it may make sense to rename it to something more ge
Build Update for apache/jackrabbit-oak
-
Build: #2822
Status: Fixed
Duration: 1832 seconds
Commit: ca711a3fc484ab153c6fbf6fa9b270c0dcfd58b7 (trunk)
Author: Thomas Mueller
Message: OAK-854 Use weight based caching (prevent forgetting to account for
map entries)
Build Update for apache/jackrabbit-oak
-
Build: #2821
Status: Fixed
Duration: 1764 seconds
Commit: e6c692ece6da603e47407a9410c2038a99e9fa92 (trunk)
Author: Thomas Mueller
Message: OAK-98 Source code formatting, code conventions, Javadocs
git-svn-id: https://sv
hmm, my commit is unrelated to the failed test.
maybe it failed for the same reasons as OAK-1118?
regards
marcel
> -Original Message-
> From: Travis CI [mailto:ju...@apache.org]
> Sent: Montag, 2. Dezember 2013 14:39
> To: oak-dev@jackrabbit.apache.org
> Subject: jackrabbit-oak build #2
Hi,
I'm currently looking to write an alternative DocumentStore
implementation (alongside MongoDocumentStore and MemoryDocumentStore).
Below are a few questions related to this:
Organization:
a) package structure: right now the existing implementations live in
org.apache.jackrabbit.oak.plug
Build Update for apache/jackrabbit-oak
-
Build: #2820
Status: Broken
Duration: 936 seconds
Commit: 1afb5b8994f01b5790123f492d10dd6b354fad5c (trunk)
Author: Marcel Reutegger
Message: OAK-1248: Return early in Commit.markChanged() when parent is already
marked
The Buildbot has detected a restored build on builder oak-trunk while building
ASF Buildbot.
Full details are available at:
http://ci.apache.org/builders/oak-trunk/builds/3856
Buildbot URL: http://ci.apache.org/
Buildslave for this Build: osiris_ubuntu
Build Reason: scheduler
Build Source Stam
The Buildbot has detected a new failure on builder oak-trunk while building ASF
Buildbot.
Full details are available at:
http://ci.apache.org/builders/oak-trunk/builds/3855
Buildbot URL: http://ci.apache.org/
Buildslave for this Build: osiris_ubuntu
Build Reason: scheduler
Build Source Stamp:
Hi,
On Mon, Dec 2, 2013 at 6:34 AM, Tobias Bocanegra wrote:
> so this means, that the SPI as we had it in Jackrabbit 2.x does no
> longer exist. And that if we want to continue to support remoting via
> DavEx (for example) users need to use the (client) code from
> Jackrabbit.
Exactly.
BR,
Juk
Thanks Jukka,
so this means, that the SPI as we had it in Jackrabbit 2.x does no
longer exist. And that if we want to continue to support remoting via
DavEx (for example) users need to use the (client) code from
Jackrabbit.
Regards, Toby
On Fri, Nov 29, 2013 at 9:27 PM, Jukka Zitting wrote:
> H
On 2.12.13 9:06 , Marcel Reutegger wrote:
Where required we could expose those implementations through the Oak
>API, which would then later on overlap the JCR 2.1 API.
do you mean JCR interface extensions in Oak or the actual Oak API in oak-core?
I wouldn't do the first now for the same reasons
Hi,
> For maximum backward compatibility and minimal impact on future
> requirements re. JCR 2.1 I suggest we implement the new APIs (at least
> as stubs) in order to avoid potential collisions.
+1 makes sense.
> Where required we could expose those implementations through the Oak
> API, which w
29 matches
Mail list logo
