Hi, Moving URIProvider from Oak 1.6 oak-core (not yet patched) to JCR API would require a patch to 2.14.2 with a new feature to make this API available to Sling and Oak 1.6. I was told patching stable branches with new features was not allowed in Oak. Only unstable branches can be patched with new features.
Moving URIProvider from Oak 1.7.9 oak-api to JCR API 2.15.6-SNAPSHOT is a viable option for Oak, but not for Sling until Oak releases 2.0, which is too late for the feature to make it into the next AEM release. I hope that makes sense, and I understood what you were asking. This issue is now redundant. See my other message and OAK-6841. Best Regards Ian On 18 October 2017 at 10:06, Angela Schreiber <anch...@adobe.com> wrote: > Hi Ian > > Sorry... I can't follow you here. Did I misunderstand your previous mail? > I am really curious why you felt that Jackrabbit API was not an option > because I don't recall that we had that option discussed in the lengthy > thread that preceded the contribution to oak-api. > > Kind regards > Angela > > > From: Ian Boston <i...@tfd.co.uk> > Date: Tuesday 17 October 2017 19:37 > > To: Angela <anch...@adobe.com> > Cc: "oak-dev@jackrabbit.apache.org" <oak-dev@jackrabbit.apache.org> > Subject: Re: Oak modularisation unstable roadmap ? > > 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 <anch...@adobe.com> 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 <i...@tfd.co.uk> >> Date: Friday 13 October 2017 18:32 >> To: Angela <anch...@adobe.com> >> Cc: "oak-dev@jackrabbit.apache.org" <oak-dev@jackrabbit.apache.org> >> 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 <anch...@adobe.com> 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" <julian.resc...@gmx.de> 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 >>> > >>> >>> >> >
