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?

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.

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

Reply via email to