sling-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Boston <...@tfd.co.uk>
Subject Re: Depending on Oak 1.7.x
Date Wed, 11 Oct 2017 10:38:37 GMT
On 11 October 2017 at 11:25, Robert Munteanu <rombert@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 <stefanegli@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" <stefanegli@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" <ianboston@gmail.com on behalf of
> > > > ieb@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
> > > >
> > > >
> > >
> > >
> > >
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message