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.uk> wrote: > >> >> > Hi, > >> >> > > >> >> > On 13 October 2017 at 15:46, Julian Sedding <jsedd...@gmail.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 <i...@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 <o...@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 (i...@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...ieb: > >> >> >> >> upgradeToOak178?expand=1 > >> >> >> >> > >> >> >> >> On 11 October 2017 at 11:38, Ian Boston <i...@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...@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...@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 > >> >> >> >> >> > > > > >> >> >> >> >> > > > > >> >> >> >> >> > > > >> >> >> >> >> > > > >> >> >> >> >> > > > >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> > > >> >> >> >> > >> >> >> >> > >> >> >> > >> >> > >> >
