Hi, I have done some more thinking and coding overnight and now think the best place for the API is in the Sling API, since thats were its used. This will unblock Sling and allow Oak to choose, or not to implement the URIProvider API.
I will adjust the Sling patch and discuss on sling-dev. Best Regards Ian On 17 October 2017 at 18:37, Ian Boston <[email protected]> wrote: > Hi, > > I dont really care where the API is, however IIUC > > Oak 1.6 needs JR API 2.14.2 (based on Slings oak.txt provisioning model) > Oak 1.7 nees JR API 2.15.5 (based on my patch to make Sling work on Oak > 1.7.8) > > To make the patch work with Oak 1.6 would mean patching the JR API 2.14.2, > which is a stable branch of an earlier version and is governed by the same > rules patching Oak 1.6 was, or in other words. If patching JR API 2.14.2 > with a new feature is Ok, then by the same logic, so should patching Oak > 1.6.x > > ----------------------------------------------- > > I dont want to create extra work. Getting this feature in to Oak and Sling > is not simple or easy and I would much rather the patch that was merged and > released in Oak 1.7.9 is reverted before it is released in 1.7.10 or a > stable release. There were plenty of objections to the concept. I dont > think anyone was really happy with the idea. The difficulties here make me > think it was not to be. > > Perhaps it would be better done by the Oak team through its normal > planning process, working its way through an unstable release, rather than > as a wild contributed patch from someone outside the team who doesn't > really understand how Oak works. > > Best Regards > Ian > > On 17 October 2017 at 18:14, Angela Schreiber <[email protected]> wrote: > >> 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]> >> Date: Friday 13 October 2017 18:32 >> To: Angela <[email protected]> >> Cc: "[email protected]" <[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]> 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]> 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 >>> > >>> >>> >> >
