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 > > > > > > > > > > > > > > > > > > >
