I would appreciate some reasoning and also a clear differentiation between Oak and Jackrabbit API. The one from Julian is not too convincing for me (yet):
- 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 > Well, the same stability as for Jackrabbit API I would say, there is semantic > versioning in place AFAICS. - Jackrabbit API is implemented by both classic Jackrabbit and Oak (it's just that some features might not be available when using classic Jackrabbit). > Why should we extend Jackrabbit API for features only implemented by Oak (and > not Jackrabbit 2)? Why not using Oak API for those use cases? Thanks for your input, Konrad > On 21. Apr 2021, at 12:15, Angela Schreiber <[email protected]> wrote: > > hi konrad > > i commented on the issue. in general i agree with julian that this looks bad > and i am not in favor or that proposal. > > kind regards > angela > > > From: Konrad Windszus <[email protected]> > Sent: Wednesday, April 21, 2021 11:55 AM > To: [email protected] <[email protected]> > Subject: Re: Evolution of Jackrabbit API vs Oak API > > I created https://issues.apache.org/jira/browse/OAK-9416 > <https://issues.apache.org/jira/browse/OAK-9416> to track this improvement > and attached a PR. > Please have a look. > >> On 21. Apr 2021, at 11:29, Konrad Windszus <[email protected] >> <mailto:[email protected]>> wrote: >> >> >> >>> On 21. Apr 2021, at 11:19, Julian Reschke <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> Am 21.04.2021 um 10:47 schrieb Konrad Windszus: >>>> 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 >>> >>> That would introduce a dependency on the Oak API; I don't think we would >>> want that. >>> >> >> The proposal is about extending the already exported JCR class in module >> "oak-jcr" >> (https://github.com/apache/jackrabbit-oak/blob/trunk/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/Jcr.java >> >> <https://github.com/apache/jackrabbit-oak/blob/trunk/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/Jcr.java>) >> which already has and needs a dependency on "oak-api" >> (https://github.com/apache/jackrabbit-oak/blob/77f243b8b810f7c611d1b1cd9b06abfc5e546446/oak-jcr/pom.xml#L224 >> >> <https://github.com/apache/jackrabbit-oak/blob/77f243b8b810f7c611d1b1cd9b06abfc5e546446/oak-jcr/pom.xml#L224>) >> >>> Best regards, Julian
