What about providing a bridge from JCR to Oak API by adding the following
method to org.apache.jackrabbit.oak.jcr.JCR:
@NotNull
public static org.apache.jackrabbit.oak.api.ContentSession
toContentSession(javax.jcr.Session session)
that can return the underlying Oak API entity if the JCR session is backed by
Oak, otherwise throws an ISE?
IMHO it doesn't make sense to duplicate methods exposed by Oak API already in
Jackrabbit API...
Konrad
> On 21. Apr 2021, at 10:43, Julian Reschke <[email protected]> wrote:
>
> Am 21.04.2021 um 10:18 schrieb Konrad Windszus:
>> Thanks, that makes it even more blurry for me what is supposed to be exposed
>> by Jackrabbit API vs by Oak API if Oak is now the only implementation of
>> more recent Jackrabbit API versions...
>> ...
>
> AFAIU:
>
> - Jackrabbit API *extends* the JCR API; so it is for situations where
> you access the repo using the JCR API, but need a few extensions
>
> - Oak API should only be used if you're ok to depend on Oak as JCR
> implementation. Not sure about what stability guarantees there are
>
> - Jackrabbit API is implemented by both classic Jackrabbit and Oak (it's
> just that some features might not be available when using classic
> Jackrabbit).
>
> Best regards, Julian
