On Mon, 2017-10-16 at 20:36 -0700, Chetan Mehrotra wrote: > I think we should seriously consider the branching option and then > release Sling bundles under some qualifier version like > 1.4.7-BETA/1.4.7-EXPERIMENTAL. > > Similar approaches were used earlier in Felix to work on new in > development specs [1]. This is not the last time where a feature in > Oak needs a corresponding implementation on Sling side. So better to > have an approach which can be used later on for similar situations.
+1 on having a general approach. Yes, Sling and Jackrabbit are independent projects, with different release cycles. In practice though some features require close coordination between the two projects and it would be a shame to go through such a difficult process each time. I think the branches approach is workable, but we need to make sure we don't mess up things in terms of OSGi versioning. Another approach is to have the bundle work with older versions as well by making the feature optional. I would favour this approach but I'm not sure how feasible it is in this scenario. Robert > > regards > Chetan > [1] https://lists.apache.org/thread.html/d1c9121d2a76e78d866e0cc5e2f9 > 94ccbba7236a5051f77ec734bb2a@%3Cdev.felix.apache.org%3E > Chetan Mehrotra > > > On Mon, Oct 16, 2017 at 7:49 AM, Ian Boston <[email protected]> wrote: > > Hi, > > My first proposal used javax.net.URI. It could do that again. No > > Oak API > > required. > > Best Regards > > Ian > > > > On 16 October 2017 at 14:34, Julian Sedding <[email protected]> > > wrote: > > > > > Hi Ian > > > > > > The only bundle with a direct dependency to Oak is Sling JCR > > > Resource. > > > All other bundles you mention require an updated Sling API (for > > > ExternalizableInputStream), which should be no problem. > > > > > > In detail: > > > - Sling API defines ExternalizableInputStream > > > - Sling JCR Resource implements ExternalizableInputStream (using > > > Oak > > > 1.7.9 internally) > > > - Sling Get Servlet leverages ExternalizableInputStream to > > > implement > > > the redirect feature > > > - Sling ResourceResolver - I think this does not need to be > > > touched at > > > all ( I may be missing something of course) > > > > > > I fail to see a solution that allows you to implement this > > > feature in > > > Sling without a direct dependency to Oak is Sling JCR Resource. > > > Hence > > > I fail to follow your argument about why your alternative > > > solution > > > would be better. > > > > > > Regards > > > Julian > > > > > > > > > On Mon, Oct 16, 2017 at 2:07 PM, Ian Boston <[email protected]> > > > wrote: > > > > Hi, > > > > I think it would be better to go back and look at the earlier > > > > proposals > > > > > > for > > > > this patch that did not require any new APIs from Oak to work. > > > > They were > > > > written that way to avoid exactly the problem of a long > > > > dependency chain > > > > now blocking the feature. > > > > > > > > Since Oak only releases its first stable release towards the > > > > end of an > > > > > > AEM > > > > GA cycle and Sling can't release anything depending on that > > > > until Oak is > > > > table, that leaves the short period between Oak going Stable > > > > and feature > > > > freeze for the next version of AEM for everything else to be > > > > done. If > > > > feature freeze is missed, then next opportunity comes a year to > > > > 18 months > > > > later, which isn't very agile and certainly not what Sling is > > > > about. > > > > > > > > Sling is an Apache project and should not really be governed by > > > > the AEM > > > > release cycle, but given there are so many Adobe employees and > > > > partners > > > > working on Sling and AEM is possibly Slings larges stakeholder > > > > that is > > > > almost impossible to avoid. > > > > > > > > So we have to find a way of living with this, which is why the > > > > first > > > > > > patch > > > > for the feature didn't require any APIs in Oak. > > > > Best Regards > > > > Ian > > > > > > > > > > > > On 16 October 2017 at 12:34, Julian Sedding <[email protected] > > > > > wrote: > > > > > > > > > Yes, branching could be an option. To avoid confusion, it may > > > > > be > > > > > prudent to do any releases from such branches only with odd > > > > > bundle > > > > > micro-versions and a qualifier. Such a version number could > > > > > e.g. look > > > > > like this: 1.4.7-EXPERIMENTAL. > > > > > > > > > > That way a released artifact is clearly labelled as being > > > > > experimental > > > > > (or whatever qualifier is chosen) and the odd micro-version > > > > > number is > > > > > one that's usually reserved for snapshots (by convention in > > > > > Sling). > > > > > This may cause people experimenting with such bundles some > > > > > minor > > > > > hickups (e.g. snapshot overriding experimental release > > > > > bundle), but > > > > > that should be acceptable IMHO. > > > > > > > > > > Regards > > > > > Julian > > > > > > > > > > > > > > > > > > > > On Fri, Oct 13, 2017 at 6:37 PM, Ian Boston <[email protected]> > > > > > wrote: > > > > > > Hi, > > > > > > The bundles are > > > > > > > > > > > > Sling API > > > > > > Sling ResourceResolver > > > > > > Sling JCR Resource > > > > > > Sling GET Servlets. > > > > > > > > > > > > given these will probably get fixed between now and when > > > > > > Oak 2.0 is > > > > > > released and could end up in a product I don't think an > > > > > > internal > > > > > > release > > > > > is > > > > > > a viable low risk option. > > > > > > > > > > > > I think the only viable option is to wait for Oak 2.0 to be > > > > > > released, > > > > > > > > > > given > > > > > > the Oak backport policy of no new features or API changes > > > > > > in stable > > > > > > branches. > > > > > > Best Regards > > > > > > Ian > > > > > > > > > > > > > > > > > > On 13 October 2017 at 17:25, Chetan Mehrotra < > > > > > > [email protected]> > > > > > > wrote: > > > > > > > > > > > > > Another possible option can be to branch such bundles > > > > > > > which depend on > > > > > > > Oak API and do unstable releases for them i.e. only odd > > > > > > > version > > > > > > > release. This would allow implementing parts in Sling > > > > > > > which rely on > > > > > > > new features implement in Oak trunk > > > > > > > > > > > > Chetan Mehrotra > > > > > > > > > > > > > > > > > > > > > On Fri, Oct 13, 2017 at 8:25 PM, Ian Boston <[email protected] > > > > > > > k> wrote: > > > > > > > > Hi, > > > > > > > > > > > > > > > > On 13 October 2017 at 15:46, Julian Sedding <jsedding@g > > > > > > > > mail.com> > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > AFAIK Oak does not use semantic versioning for > > > > > > > > > packages within > > > > > > uneven > > > > > > > > > minor version changes (i.e. 1.8 will be baselined > > > > > > > > > against 1.6). > > > > > > This > > > > > > > > > gives the Oak dev team freedom to experiment with API > > > > > > > > > changes > > > > > > within > > > > > > > > > the uneven "development" version (i.e. currently > > > > > > > > > 1.7). > > > > > > > > > > > > > > > > > > Sling, on the other hand uses semantic versioning and > > > > > > (implicitly?) > > > > > > > > > requires that any bundle can be released at any > > > > > > > > > point. This > > > > > > > > > requirement conflicts with Oak's "unstable" > > > > > > > > > development releases > > > > > > in > > > > > so > > > > > > > > > far as Sling should not create any releases that > > > > > > > > > reference Oak's > > > > > > > > > intermittent (non semantic) package versions. Doing > > > > > > > > > so could lead > > > > > > to > > > > > > > > > update problems or badly wired OSGi bundles down the > > > > > > > > > line. > > > > > > > > > > > > > > > > > > IMHO the "unstable" label of Oak's uneven minor > > > > > > > > > versions refers > > > > > > not > > > > > to > > > > > > > > > unstable or poorly tested code, but acknowledges that > > > > > > > > > semantic > > > > > > > > > versioning is only enforced in releases with even > > > > > > > > > minor version > > > > > > > > > numbers. > > > > > > > > > > > > > > > > > > This implies that using "unstable" Oak for testing > > > > > > > > > within Sling > > > > > > > > > > should > > > > > > > > > be fine. Releasing bundles with "unstable" Oak > > > > > > > > > dependencies is > > > > > > > > > definitely slippery slope, even though it does not > > > > > > > > > have to lead to > > > > > > > > > problems. > > > > > > > > > > > > > > > > > > > > > > > > > Underlined by the appearance of some new bundles in > > > > > > > > 1.7.9 that were > > > > > > > > > > not > > > > > > > > there in 1.7.8, however AFAIK the package versions were > > > > > > > > not > > > > > > changed. > > > > > > > > > > > > > > > > Since I was wrong to assert 1.7.8 was close to 1.8.0 > > > > > > > > (see other > > > > > > > > > > thread), > > > > > > > I > > > > > > > > have asked oak-dev to clarify it it is or not. If its > > > > > > > > not, I also > > > > > > dont > > > > > > > want > > > > > > > > to slip down that slope. > > > > > > > > Best Regards > > > > > > > > Ian > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Remains the tricky question: how do we build on > > > > > > > > > cutting edge Oak > > > > > > > > > features? Branches could be one option (especially > > > > > > > > > once we're on > > > > > > > > > > Git), > > > > > > > > > with no (official) releases from the branch. > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > Julian > > > > > > > > > > > > > > > > > > > > > > > > > > > On Fri, Oct 13, 2017 at 11:56 AM, Ian Boston <ieb@tfd > > > > > > > > > .co.uk> > > > > > > wrote: > > > > > > > > > > Hi, > > > > > > > > > > My View is that it would be dangerous to depend on > > > > > > > > > > 1.11.1 but > > > > > > safe > > > > > to > > > > > > > > > > depend on 1.11.25 if 1.11.25 was known to be near > > > > > > > > > > to the branch > > > > > > to > > > > > > > > > 1.12.x. > > > > > > > > > > The closer to 1.11.1, the greater the risk of > > > > > > > > > > instability, the > > > > > > > > > > closer > > > > > > > to > > > > > > > > > > 1.12.x the less the risk. > > > > > > > > > > > > > > > > > > > > IIUC Oak have started to discuss the possibility of > > > > > > > > > > branching > > > > > > > > > > 1.8.x, > > > > > > > > > which > > > > > > > > > > makes 1.7.9 relatively close to that branch. That > > > > > > > > > > said, I made > > > > > > an > > > > > API > > > > > > > > > > change that appeared in 1.7.9 ;). It all depends on > > > > > > > > > > the detail > > > > > > in > > > > > > > every > > > > > > > > > > case. There are no rules that always work. > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > > > > > Ian > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 12 October 2017 at 16:28, Matt Ryan <oss@mvryan. > > > > > > > > > > org> wrote: > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > I’m curious to explore the reasoning behind the > > > > > > > > > > > general > > > > > > principle > > > > > of > > > > > > > > > only > > > > > > > > > > > having dependencies on stable Oak releases. Of > > > > > > > > > > > course I > > > > > > > > > > understand > > > > > > > the > > > > > > > > > > > importance of keeping the codebase on a solid > > > > > > > > > > > foundation and > > > > > > thus > > > > > to > > > > > > > > > want > > > > > > > > > > > stable releases for dependencies. My question > > > > > > > > > > > is, what > > > > > > exactly is > > > > > > > > > meant by > > > > > > > > > > > “stable”? > > > > > > > > > > > > > > > > > > > > > > I expect we regard even-numbered minor versions > > > > > > > > > > > in Oak as > > > > > > stable > > > > > > > > > releases > > > > > > > > > > > because that’s how the Oak project refers to such > > > > > > > > > > > releases. > > > > > > > > > > Based on > > > > > > > > > that > > > > > > > > > > > reasoning, Oak 1.7.8 is unstable by > > > > > > > > > > > definition. I’d then argue > > > > > > > > > > that > > > > > > > if > > > > > > > > > Oak > > > > > > > > > > > were to change their versioning model (which I’m > > > > > > > > > > > not proposing > > > > > > - > > > > > and > > > > > > > I > > > > > > > > > > > wouldn’t propose it here if I was proposing such > > > > > > > > > > > a thing > > > > > > anyway) > > > > > such > > > > > > > > > that > > > > > > > > > > > a “stable” Oak release is defined by some other > > > > > > > > > > > means (say, any > > > > > > > > > > > > > > version > > > > > > > > > > > that passes the entire test suite), Oak 1.7.10 > > > > > > > > > > > may be > > > > > > considered > > > > > > > stable > > > > > > > > > - > > > > > > > > > > > in which case the concern to rely on that version > > > > > > > > > > > would be > > > > > > > > > > lower. In > > > > > > > > > other > > > > > > > > > > > words: If Oak were to declare a version as > > > > > > > > > > > stable, is that > > > > > > > > > > > > > > sufficient > > > > > > > > > for > > > > > > > > > > > us to rely on those package versions? Or would > > > > > > > > > > > we do our own > > > > > > > > > > > > > > validation > > > > > > > > > > > anyway? > > > > > > > > > > > > > > > > > > > > > > My point is that it appears the resistance to use > > > > > > > > > > > a particular > > > > > > Oak > > > > > > > > > version > > > > > > > > > > > is based on Oak not declaring it as stable. Yet > > > > > > > > > > > Sling probably > > > > > > > > > > > > > > depends > > > > > > > > > on > > > > > > > > > > > other packages that have different criteria for > > > > > > > > > > > being > > > > > > considered > > > > > > > stable > > > > > > > > > - > > > > > > > > > > > some which may not even declare a particular > > > > > > > > > > > version as such. > > > > > > I > > > > > > > don’t > > > > > > > > > have > > > > > > > > > > > concrete knowledge about that of course, just a > > > > > > > > > > > hunch. > > > > > > > > > > > > > > > > > > > > > > But if that’s the case, perhaps it is worthwhile > > > > > > > > > > > to consider > > > > > > the > > > > > > > reason > > > > > > > > > > > this policy was adopted for Oak packages, and > > > > > > > > > > > maybe in > > > > > > > > > > understanding > > > > > > > > > what > > > > > > > > > > > the real goal is we can find a way where we don’t > > > > > > > > > > > feel > > > > > > concerned > > > > > > > > > updating > > > > > > > > > > > dependencies to an “unstable” Oak release. For > > > > > > > > > > > example, if > > > > > > such a > > > > > > > > > release > > > > > > > > > > > passes all Oak tests and all Sling tests, maybe > > > > > > > > > > > that’s > > > > > > acceptable. > > > > > > > > > > > > > > > > > > > > > > -MR > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On October 12, 2017 at 8:34:50 AM, Ian Boston (ie > > > > > > > > > > > [email protected]) > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > Here is a patch to make Sling work with Oak > > > > > > > > > > > 1.7.8. Once I > > > > > > fixed a > > > > > > > full > > > > > > > > > > > build (just did a pull request) it passes a full > > > > > > > > > > > IT build. The > > > > > > > > > > patch > > > > > > > > > > > updates the paxexam setup so IT tests that uses > > > > > > > > > > > that will test > > > > > > > > > > > > > > against > > > > > > > > > Oak > > > > > > > > > > > 1.7.8. I also tested with 1.8-SNAPSHOT so this > > > > > > > > > > > should be good > > > > > > for > > > > > > > > > anything > > > > > > > > > > > after 1.7.8. We might wait till 1.7.10 comes out > > > > > > > > > > > as IIUC this > > > > > > will > > > > > > > > > > > include OAK-6575. > > > > > > > > > > > > > > > > > > > > > > wdyt, mege when 1.7.10 is out and upgrade to a > > > > > > > > > > > stable 1.8 when > > > > > > its > > > > > > > cut ? > > > > > > > > > > > Best Regards > > > > > > > > > > > Ian > > > > > > > > > > > > > > > > > > > > > > 1 > > > > > > > > > > > https://github.com/apache/sling/compare/trunk...i > > > > > > > > > > > eb: > > > > > > > > > > > upgradeToOak178?expand=1 > > > > > > > > > > > > > > > > > > > > > > On 11 October 2017 at 11:38, Ian Boston <ieb@tfd. > > > > > > > > > > > co.uk> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 11 October 2017 at 11:25, Robert Munteanu < > > > > > > > > > > [email protected]> > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, 2017-10-11 at 11:16 +0100, Ian Boston > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > Switching to depend on Oak 1.7 requires > > > > > > > > > > > > > > upgrading > > > > > > oak-server > > > > > to > > > > > > > use > > > > > > > > > > > > > > 1.7 or > > > > > > > > > > > > > > later. > > > > > > > > > > > > > > There has been some incompatible changes at > > > > > > > > > > > > > > a bundle level > > > > > > > > > > and > > > > > > > > > > > > > > package > > > > > > > > > > > > > > level between 1.6 and 1.7 so its not as > > > > > > > > > > > > > > simple has > > > > > > changing > > > > > the > > > > > > > > > > > > > > versions. > > > > > > > > > > > > > > For instance oak-api bundle didnt existi in > > > > > > > > > > > > > > 1.6 and > > > > > > > > > > > > > > NodeAggregator > > > > > > > > > > > > > > class > > > > > > > > > > > > > > doesn't appear to exist in 1.7. oak-server > > > > > > > > > > > > > > wont build > > > > > > > > > > without a > > > > > > > > > > > > > > patch. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Obviously, if you have an oak-server or > > > > > > > > > > > > > > equivalent that > > > > > > > > > > already > > > > > > > > > > > > > > depends on > > > > > > > > > > > > > > 1.7 or later, then its trivial, but Sling > > > > > > > > > > > > > > doesn't. > > > > > > > > > > > > > > > > > > > > > > > > > > So we need need to make oak-server and > > > > > > > > > > > > > jcr.resource > > > > > > dependent > > > > > on > > > > > > > Oak > > > > > > > > > > > > > 1.7, right? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Yes, working on a patch now. > > > > > > > > > > > > Compiles but all ITs fail. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I would guess that oak-server is not such a > > > > > > > > > > > > > big issue. Is it > > > > > > > > > > > > > > possible > > > > > > > > > > > > > to make the dependency from jcr.resource to > > > > > > > > > > > > > the newer oak > > > > > > api > > > > > > > > > optional? > > > > > > > > > > > > > If the bundle would also run on Oak 1.6 I > > > > > > > > > > > > > guess there would > > > > > > be > > > > > no > > > > > > > > > > > > > issue. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > In the original patch with AdapterFactories > > > > > > > > > > > > that would have > > > > > > been > > > > > > > > > simple > > > > > > > > > > > as > > > > > > > > > > > > it was very loosly coupled for exactly this > > > > > > > > > > > > reason, however > > > > > > that > > > > > > > patch > > > > > > > > > > > was > > > > > > > > > > > > rejected by this list, and a much more tightly > > > > > > > > > > > > bound patch[1] > > > > > > > > > > was > > > > > > > > > > > > required. Making HelperData, core to Sling GET > > > > > > > > > > > > Servlets, load > > > > > > > > > > > > > > safely > > > > > > > > > > > with > > > > > > > > > > > > one of its imports optional will be messy and > > > > > > > > > > > > will make its > > > > > > > > > > method > > > > > > > > > calls > > > > > > > > > > > > nasty. > > > > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > > > > > > > Ian > > > > > > > > > > > > > > > > > > > > > > > > 1 https://github.com/apache/sling/compare/trunk > > > > > > > > > > > > ...ieb:OAK- > > > > > > > > > > 6575-3-2 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > > > > > > > > > > > > > Robert > > > > > > > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > > > > > > > > > Ian > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 11 October 2017 at 11:07, Stefan Egli < > > > > > > > > > > [email protected] > > > > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Having said that, the only bullet to bite > > > > > > > > > > > > > > > when > > > > > > switching to > > > > > > > Oak > > > > > > > > > > > > > > > 1.7.x is > > > > > > > > > > > > > > > increased maintenance effort: the > > > > > > > > > > > > > > > affected bundles will > > > > > > > > > > become > > > > > > > > > > > > > > > backwards > > > > > > > > > > > > > > > incompatible wrt Oak 1.6.x and if they > > > > > > > > > > > > > > > need to be > > > > > > patched > > > > > it > > > > > > > > > would > > > > > > > > > > > > > > > not be > > > > > > > > > > > > > > > possible to do so in trunk anymore. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > > > Stefan > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 11/10/17 12:03, "Stefan Egli" <stefane > > > > > > > > > > > > > > > [email protected] > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Ian, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I don't see a problem with having a > > > > > > > > > > > > > > > > dependency on an > > > > > > > > > > > > > > unstable > > > > > > > > > Oak > > > > > > > > > > > > > > > > 1.7.x in > > > > > > > > > > > > > > > > Sling. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Actual deployments can still, > > > > > > > > > > > > > > > > independent of this, > > > > > > make a > > > > > > > call > > > > > > > > > > > > > > > > whether or > > > > > > > > > > > > > > > > not they want to actually run on Oak > > > > > > > > > > > > > > > > 1.7.x or wait for > > > > > > > > > > Oak > > > > > > > 1.8 > > > > > > > > > > > > > > > > (which is > > > > > > > > > > > > > > > > advisable). IMO having this dependency > > > > > > > > > > > > > > > > doesn't imply > > > > > > on > > > > > > > which > > > > > > > > > > > > > > > > version it > > > > > > > > > > > > > > > > will ultimately run. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > > > > Stefan > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 11/10/17 11:54, "Ian Boston" <ianbos > > > > > > > > > > > > > > > > [email protected] > > > > > > on > > > > > > > behalf > > > > > > > > > > > of > > > > > > > > > > > > > > > > [email protected]> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > Oak 1.7.x is Oak unstable release > > > > > > > > > > > > > > > > > branch working > > > > > > > > > > towards > > > > > > > 1.8. > > > > > > > > > > > > > > > > > I have a feature in SLING-7140 that > > > > > > > > > > > > > > > > > is blocked by an > > > > > > > > > > API > > > > > > > > > change > > > > > > > > > > > > > > > > > in Oak > > > > > > > > > > > > > > > > > present in 1.8-SNAPSHOT and available > > > > > > > > > > > > > > > > > as an unmerged > > > > > > > > > > but > > > > > > > > > tested > > > > > > > > > > > > > > > > > patch to > > > > > > > > > > > > > > > > > Oak 1.6.x. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The Oak team are unwilling merge the > > > > > > > > > > > > > > > > > patch to 1.6 > > > > > > and > > > > > have > > > > > > > > > > > > > > > > > asked that > > > > > > > > > > > > > > > > > Sling > > > > > > > > > > > > > > > > > depend on the latest release of Oak > > > > > > > > > > > > > > > > > 1.7. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > How does the Sling team feel about > > > > > > > > > > > > > > > > > this ? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The patch for SLING-7140 cant be > > > > > > > > > > > > > > > > > merged until the > > > > > > API > > > > > is > > > > > > > > > > > > > > > > > available in Oak > > > > > > > > > > > > > > > > > in some form and I don't want to > > > > > > > > > > > > > > > > > depend on Oak > > > > > > > > > > > > > > 1.8-SNAPSHOT > > > > > > > > > as > > > > > > > > > > > > > > > > > this will > > > > > > > > > > > > > > > > > block Sling releases of the bundles > > > > > > > > > > > > > > > > > involved. > > > > > > > > > > > > > > > > > Best Regards > > > > > > > > > > > > > > > > > Ian > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
