Hi, I really do not think that my mistake trying to get a feature into Oak then Sling warrants the extra work of experimental branches. I am certain those waiting for the feature, can wait a little longer, failing that I am reasonably certain that I can find a different way of introducing the feature that doesn't depend any changes in Oak.
Best Regards Ian On 17 October 2017 at 08:54, Robert Munteanu <romb...@apache.org> wrote: > 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 <i...@tfd.co.uk> 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 <jsedd...@gmail.com> > > > 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 <i...@tfd.co.uk> > > > > 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 <jsedd...@gmail.com > > > > > > 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 <i...@tfd.co.uk> > > > > > > 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 < > > > > > > > > chetan.mehro...@gmail.com> > > > > > > > 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 <i...@tfd.co.u > > > > > > > > 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 > > > > > > > > > > > > b...@tfd.co.uk) > > > > > > > > > > > > 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 < > > > > > > > > > > > > romb...@apache.org> > > > > > > > > > > > > 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 < > > > > > > > > > > > > stefane...@apache.org > > > > > > > > > > > > > > > > > > > > > > > > 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 > > > > > > > > > > > > > > > > g...@apache.org > > > > > > > > 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 > > > > > > > > > > > > > > > > > t...@gmail.com > > > > > > > > on > > > > > > > > behalf > > > > > > > > > > > > of > > > > > > > > > > > > > > > > > i...@tfd.co.uk> 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
