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]> wrote: >> >> > Hi, >> >> > >> >> > On 13 October 2017 at 15:46, Julian Sedding <[email protected]> >> 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 <[email protected]> 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 <[email protected]> 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 ([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...ieb: >> >> >> >> upgradeToOak178?expand=1 >> >> >> >> >> >> >> >> On 11 October 2017 at 11:38, Ian Boston <[email protected]> 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" <[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" <[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 >> >> >> >> >> > > > >> >> >> >> >> > > > >> >> >> >> >> > > >> >> >> >> >> > > >> >> >> >> >> > > >> >> >> >> >> >> >> >> >> >> >> >> >> >> > >> >> >> >> >> >> >> >> >> >> >> >> >> >>
