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. regards Chetan [1] https://lists.apache.org/thread.html/d1c9121d2a76e78d866e0cc5e2f994ccbba7236a5051f77ec734bb2a@%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]> 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 >> >> >> >> >> >> > > > >> >> >> >> >> >> > > > >> >> >> >> >> >> > > >> >> >> >> >> >> > > >> >> >> >> >> >> > > >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> > >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >>
