Hi Ian Would you mind sharing your thoughts and why you think moving it to Jackrabbit API is not an option?
As far as I remember the Sling community has been particularly vocal about NOT introducing dependencies to any particular JCR implementation. With this history in mind it would look a lot more Sling-compatible to have API extensions on the same layer than JCR and that would be Jackrabbit API (as there is currently no easy way to extend the JCR specification). From a Sling point of view the Oak API is an implementation detail of a particular JCR implementation (namely Jackrabbit Oak). Kind regards Angela From: Ian Boston <[email protected]<mailto:[email protected]>> Date: Friday 13 October 2017 18:32 To: Angela <[email protected]<mailto:[email protected]>> Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Re: Oak modularisation unstable roadmap ? Hi, Marcel suggested this off list to me yesterday. I have thought about it and think its not an option. Probably ok of Oak, but not for anyone downstream. Taking that route means.... Oak 1.7.9 has been released so the patch in OAK-6575 would need to be reverted ASAP to avoid the oak-api package being used. Oak 1.6.5 depends on Jackrabbit API 2.14.4 IIRC, Oak 1.7.9 depends on Jackrabbit API 2.15.0 So a backport will still be required to JR API 2.14.6, breaking Oaks backport rule of no new features. It looks like JR API 2.15.x can't be used with Oak 1.6 since 2.15.x depends on Lucene 3.6 and 2.14 has references to Lucene 2.4. Coupled with, it won't be possible to test Sling until Oak 2.0 is released. I am not comfortable asking for a vote on a Sling release I know hasn't been tested with integration tests. I have asked those who are waiting for this feature if they can wait till Oak 2.0 is released. Best Regards Ian On 13 October 2017 at 17:09, Angela Schreiber <[email protected]<mailto:[email protected]>> wrote: I share Julians concerns. In a private conversation Marcel suggested to reconsider placing the new API into oak-api and put it to Jackrabbit API instead. If there is really no Oak dependency in there that would make a lot of sense to me. In particular since the Sling community used to be quite strict about any kind of implementation dependency to Jackrabbit/Oak and only want to depend on JCR... Jackrabbit API is the natural extension of JCR, where as Oak API is on a different layer in the stack and from a Sling PoV a implementation detail of a JCR implementation. So, I would opt for taking following up on Marcels suggestion. Kind regards Angela On 13/10/17 17:22, "Julian Reschke" <[email protected]<mailto:[email protected]>> wrote: >On 2017-10-13 17:02, Ian Boston wrote: >> Hi, >> Thank you for the clarification. It sounds like Sling can't safely bind >>to >> 1.7.x and safely make releases that will not cause problems with package >> versions later. That blocks Sling from binding to any features not >> backported to a stable version of Oak. > >That blocks Sling from *releasing* something as stable which relies on >an unstable Oak feature. > >As far as I can tell, it doesn't mean that Sling can't experiment with >it, and even make experimental releases for Sling's downstream users. > >> The (obvious) reason for asking was I still need to get OAK-6575 into >> Sling. Since that wont be possible til 1.8 is released could the 1.6 >> backport patch I did for 1.6 be reconsidered ? > >I understand your pain, but forcing something into a stable release of >Oak just because Sling's release model is incompatible with Oak's makes >me really uncomfortable. > >Best regards, Julian >
