jackrabbit oak support

[dbu]

it would be nice to have a working setup with jackrabbit oak.

a first step would be to wire the jcr to davex libraries around oak. once the oak http api starts to exist, we could also work with that one.

adobe people told us that using the davex libraries should work. but there is no ready made .jar like for jackrabbit 2.x so it would need some investigating into the internals of oak and jackrabbit.

[lsmith77]

see this thread for some hints on how to configure oak with the old http api
http://mail-archives.apache.org/mod_mbox/jackrabbit-oak-dev/201407.mbox/%3C53BE9DF1.50003@apache.org%3E

[levuro]

Hi there - i see there are now regular releases of OAK and I am wondering if there is any progress on the HTTP api side? from what i understood its there but it does not support the multi - fetches used by jackrabbit. Are they planning to do this or will jackrabbit need some refactoring?

[dbu]

the "old" jackrabbit remoting layer should work with oak but needs to be bundled which exceeds my java skills. somebody would need to dig into that and have a jar / war file that can be run with oak and the jcr remoting of jackrabbit. then we could see with the tests if that works or not.

but in other news, oak is starting to think about adding a REST layer for remoting access. @lsmith77 and me will meet adobe people tomorrow to discuss that. the first draft idea is at https://github.com/francescomari/oak-remote

[dbu]

one of probably many things to look at is https://issues.apache.org/jira/browse/OAK-533 - maybe oak will do something different with mix:lastModified

[levuro]

hi @dbu - were there any recent development on the rest layer of oak?

[gmoigneu]

Hi. Have you made any progress on Oak or decided to cancel this one ?

[lsmith77]

we have not invested anymore time into this .. afaik the Oak HTTP interface is making good progress .. so it just needs someone to put int the time.

[koemeet]

Isn't Oak a drop-in replacement for Jackrabbit 2.x? Or does there need to be an implementation to support it in jackalope?

[dbu]

the JCR specification does not change for oak, but in jackalope-jackrabbit we do not call java. instead, we use the jackrabbit remoting protocol which is not part of any official standard. it turned out that its possible to wrap the jackrabbit remoting to jcr layer around oak, but there seem to be no official distributions of this set up. and when we tried, there where a few differences like oak did not support multiple workspaces. see also #109

the oak people where also talking about a new, cleaner remoting protocol for oak. if we could dock to that, a new Client would need to be written, but it hopefully could look a lot cleaner. i did not follow up on things there recently, being busy with keeping the cmf up to date with symfony 2.7 and now 3.0. if you are interested in working on this, i can look for the current state of the oak remoting and try bring you into contact with the oak/jackrabbit people that helped us in the past.

[ftaiolivista]

I see OAK now has an HTTP api. In this repository, there is two oak branch but seems abandoned-ware. Any plan for OAK transport implementation?

[lsmith77]

not that I am aware of but it would be awesome to have this!
note this might also be an opportunity to further move the current transport API away from being based on the old Jackrabbit XML API.

[dbu]

i also would not know of anybody currently working on that. if you want to give it a go, please do. either based on the current Transport implementation or with a cleaned up approach that would end up being a version 2 of jackalope.