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 <[email protected]<mailto:[email protected]>> Date: Tuesday 17 October 2017 19:37 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, 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]<mailto:[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]<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 >
