Depending on Oak 1.7.x

[Ian Boston <ie...@tfd.co.uk>]

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

Re: Depending on Oak 1.7.x

[Oliver Lietz <ap...@oliverlietz.de>]

On Wednesday 11 October 2017 12:15:25 Konrad Windszus wrote:
> Adjusting the dependency implicitly has an effect on the import-version
> range being calculated by bnd for Sling bundles depending on Oak. Therefore
> depending on 1.7 most probably prevents the same Sling bundle from running
> with Oak 1.6. We had this discussion before and basically we were advised
> to only depend on the stable versions of Oak back then.

We should use releases from stable branches only, whether Oak or Jackrabbit or 
any other dependency.

Regards,
O.

> So I would much rather prefer to still rely on the last stable release.
> Konrad
> 
> > On 11. Oct 2017, at 12:03, Stefan Egli <st...@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

Re: Depending on Oak 1.7.x

[Konrad Windszus <ko...@gmx.de>]

Adjusting the dependency implicitly has an effect on the import-version range being calculated by bnd for Sling bundles depending on Oak.
Therefore depending on 1.7 most probably prevents the same Sling bundle from running with Oak 1.6.
We had this discussion before and basically we were advised to only depend on the stable versions of Oak back then.

So I would much rather prefer to still rely on the last stable release.
Konrad


> On 11. Oct 2017, at 12:03, Stefan Egli <st...@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
> 
> 

Re: Depending on Oak 1.7.x

[Chetan Mehrotra <ch...@gmail.com>]

> @Chetan. THere are 4-5 bundles to release. All may need other releases for
> other fixes critical to the current roadmap. I agree that doing an
> internal/experimenta/branched release of a one bundle on the periphery of
> Sling would be ok, but IMHO doing an experimental release of most of the
> bundles core to Sling is going to lead to mess

Ack but then thats the right usage of branch. Some feature require
coordinate work across modules (in this case it just happens one of
the module is outside Sling i.e. Oak) and only safe way to do that is
to have branch. But yes merging stuff would add some overhead.

> Others have already stated their objection to the concept of internal releases.

To clarify proposal was not for internal release but more of release
with some qualifier in version
Chetan Mehrotra


On Tue, Oct 17, 2017 at 1:09 PM, Ian Boston <ie...@tfd.co.uk> wrote:
> Hi,
> @Julian
> It would need the Oak S3 DataStore to have an dependency on Sling Adapter
> factory and then do a Resource -> URI adaption for Resources that
> represented a binary. No new API in Oak.
> That said, I think we went down this rabbit hole and concluded that Oak
> wasnt willing to have any dependencies on Sling. The same logic was
> probably applied to the oak-server bundle which is in Sling, but would more
> naturally live in Oak. Replacing the Oak S3 DataStore with a Sling version
> that supports these types of conversion would make the problem go away, as
> would moving the URIProvider into the Sling API.
>
> IMHO, Oak should depend on Sling API which is always stable and versioned
> correctly for use in OSGi.
>
>
> @Chetan. THere are 4-5 bundles to release. All may need other releases for
> other fixes critical to the current roadmap. I agree that doing an
> internal/experimenta/branched release of a one bundle on the periphery of
> Sling would be ok, but IMHO doing an experimental release of most of the
> bundles core to Sling is going to lead to mess. Others have already stated
> their objection to the concept of internal releases.
>
> Best Regards
> Ian
>
> On 17 October 2017 at 07:27, Julian Sedding <js...@gmail.com> wrote:
>
>> Hi Ian
>>
>> How and where was access to the javax.net.URI instance implemented?
>>
>> To my understanding the problem is consuming the changed Oak API in
>> Sling. The additional Sling API should be no problem as it does not
>> create a dependency to Oak. What am I missing?
>>
>> Regards
>> Julian
>>
>>
>> On Mon, Oct 16, 2017 at 4:49 PM, Ian Boston <ie...@tfd.co.uk> 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 <js...@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 <ie...@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 <js...@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 <ie...@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.mehrotra@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 <ie...@tfd.co.uk>
>> wrote:
>> >> >> >> > Hi,
>> >> >> >> >
>> >> >> >> > On 13 October 2017 at 15:46, Julian Sedding <jsedding@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 <ie...@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 <os...@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 (
>> ieb@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 <ie...@tfd.co.uk>
>> wrote:
>> >> >> >> >> >>
>> >> >> >> >> >> >
>> >> >> >> >> >> >
>> >> >> >> >> >> > 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
>> >> >> >> >> >> >> > > >
>> >> >> >> >> >> >> > > >
>> >> >> >> >> >> >> > >
>> >> >> >> >> >> >> > >
>> >> >> >> >> >> >> > >
>> >> >> >> >> >> >>
>> >> >> >> >> >> >>
>> >> >> >> >> >> >
>> >> >> >> >> >>
>> >> >> >> >> >>
>> >> >> >> >>
>> >> >> >>
>> >> >>
>> >>
>>

Re: Depending on Oak 1.7.x

[Ian Boston <ie...@tfd.co.uk>]

Hi,
@Julian
It would need the Oak S3 DataStore to have an dependency on Sling Adapter
factory and then do a Resource -> URI adaption for Resources that
represented a binary. No new API in Oak.
That said, I think we went down this rabbit hole and concluded that Oak
wasnt willing to have any dependencies on Sling. The same logic was
probably applied to the oak-server bundle which is in Sling, but would more
naturally live in Oak. Replacing the Oak S3 DataStore with a Sling version
that supports these types of conversion would make the problem go away, as
would moving the URIProvider into the Sling API.

IMHO, Oak should depend on Sling API which is always stable and versioned
correctly for use in OSGi.


@Chetan. THere are 4-5 bundles to release. All may need other releases for
other fixes critical to the current roadmap. I agree that doing an
internal/experimenta/branched release of a one bundle on the periphery of
Sling would be ok, but IMHO doing an experimental release of most of the
bundles core to Sling is going to lead to mess. Others have already stated
their objection to the concept of internal releases.

Best Regards
Ian

On 17 October 2017 at 07:27, Julian Sedding <js...@gmail.com> wrote:

> Hi Ian
>
> How and where was access to the javax.net.URI instance implemented?
>
> To my understanding the problem is consuming the changed Oak API in
> Sling. The additional Sling API should be no problem as it does not
> create a dependency to Oak. What am I missing?
>
> Regards
> Julian
>
>
> On Mon, Oct 16, 2017 at 4:49 PM, Ian Boston <ie...@tfd.co.uk> 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 <js...@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 <ie...@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 <js...@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 <ie...@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.mehrotra@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 <ie...@tfd.co.uk>
> wrote:
> >> >> >> > Hi,
> >> >> >> >
> >> >> >> > On 13 October 2017 at 15:46, Julian Sedding <jsedding@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 <ie...@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 <os...@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 (
> ieb@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 <ie...@tfd.co.uk>
> wrote:
> >> >> >> >> >>
> >> >> >> >> >> >
> >> >> >> >> >> >
> >> >> >> >> >> > 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
> >> >> >> >> >> >> > > >
> >> >> >> >> >> >> > > >
> >> >> >> >> >> >> > >
> >> >> >> >> >> >> > >
> >> >> >> >> >> >> > >
> >> >> >> >> >> >>
> >> >> >> >> >> >>
> >> >> >> >> >> >
> >> >> >> >> >>
> >> >> >> >> >>
> >> >> >> >>
> >> >> >>
> >> >>
> >>
>

Re: Depending on Oak 1.7.x

[Julian Sedding <js...@gmail.com>]

Hi Ian

How and where was access to the javax.net.URI instance implemented?

To my understanding the problem is consuming the changed Oak API in
Sling. The additional Sling API should be no problem as it does not
create a dependency to Oak. What am I missing?

Regards
Julian


On Mon, Oct 16, 2017 at 4:49 PM, Ian Boston <ie...@tfd.co.uk> 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 <js...@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 <ie...@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 <js...@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 <ie...@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.mehrotra@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 <ie...@tfd.co.uk> wrote:
>> >> >> > Hi,
>> >> >> >
>> >> >> > On 13 October 2017 at 15:46, Julian Sedding <js...@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 <ie...@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 <os...@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 (ieb@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 <ie...@tfd.co.uk> wrote:
>> >> >> >> >>
>> >> >> >> >> >
>> >> >> >> >> >
>> >> >> >> >> > 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
>> >> >> >> >> >> > > >
>> >> >> >> >> >> > > >
>> >> >> >> >> >> > >
>> >> >> >> >> >> > >
>> >> >> >> >> >> > >
>> >> >> >> >> >>
>> >> >> >> >> >>
>> >> >> >> >> >
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >>
>> >> >>
>> >>
>>

Re: Depending on Oak 1.7.x

[Ian Boston <ie...@tfd.co.uk>]

Hi,

I really do not think that my mistake trying to get a feature into Oak then
Sling warrants the extra work of experimental branches. I am certain those
waiting for the feature, can wait a little longer, failing that I am
reasonably certain that I can find a different way of introducing the
feature that doesn't depend any changes in Oak.


Best Regards
Ian




On 17 October 2017 at 08:54, Robert Munteanu <ro...@apache.org> wrote:

> On Mon, 2017-10-16 at 20:36 -0700, Chetan Mehrotra wrote:
> > 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.
>
> +1 on having a general approach. Yes, Sling and Jackrabbit are
> independent projects, with different release cycles. In practice though
> some features require close coordination between the two projects and
> it would be a shame to go through such a difficult process each time.
>
> I think the branches approach is workable, but we need to make sure we
> don't mess up things in terms of OSGi versioning.
>
> Another approach is to have the bundle work with older versions as well
> by making the feature optional. I would favour this approach but I'm
> not sure how feasible it is in this scenario.
>
> Robert
>
> >
> > regards
> > Chetan
> > [1] https://lists.apache.org/thread.html/d1c9121d2a76e78d866e0cc5e2f9
> > 94ccbba7236a5051f77ec734bb2a@%3Cdev.felix.apache.org%3E
> > Chetan Mehrotra
> >
> >
> > On Mon, Oct 16, 2017 at 7:49 AM, Ian Boston <ie...@tfd.co.uk> 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 <js...@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 <ie...@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 <jsedding@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 <ie...@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.mehrotra@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 <ieb@tfd.co.u
> > > > > > > > k> wrote:
> > > > > > > > > Hi,
> > > > > > > > >
> > > > > > > > > On 13 October 2017 at 15:46, Julian Sedding <jsedding@g
> > > > > > > > > mail.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 <ieb@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 <oss@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 (ie
> > > > > > > > > > > > b@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...i
> > > > > > > > > > > > eb:
> > > > > > > > > > > > upgradeToOak178?expand=1
> > > > > > > > > > > >
> > > > > > > > > > > > On 11 October 2017 at 11:38, Ian Boston <ieb@tfd.
> > > > > > > > > > > > co.uk> wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > 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" <stefane
> > > > > > > > > > > > > > > > gli@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
> > > > > > > > > > > > > > > > > ton@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
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
>
>

Re: Depending on Oak 1.7.x

[Robert Munteanu <ro...@apache.org>]

On Mon, 2017-10-16 at 20:36 -0700, Chetan Mehrotra wrote:
> 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.

+1 on having a general approach. Yes, Sling and Jackrabbit are
independent projects, with different release cycles. In practice though
some features require close coordination between the two projects and
it would be a shame to go through such a difficult process each time.

I think the branches approach is workable, but we need to make sure we
don't mess up things in terms of OSGi versioning.

Another approach is to have the bundle work with older versions as well
by making the feature optional. I would favour this approach but I'm
not sure how feasible it is in this scenario.

Robert

> 
> regards
> Chetan
> [1] https://lists.apache.org/thread.html/d1c9121d2a76e78d866e0cc5e2f9
> 94ccbba7236a5051f77ec734bb2a@%3Cdev.felix.apache.org%3E
> Chetan Mehrotra
> 
> 
> On Mon, Oct 16, 2017 at 7:49 AM, Ian Boston <ie...@tfd.co.uk> 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 <js...@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 <ie...@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 <jsedding@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 <ie...@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.mehrotra@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 <ieb@tfd.co.u
> > > > > > > k> wrote:
> > > > > > > > Hi,
> > > > > > > > 
> > > > > > > > On 13 October 2017 at 15:46, Julian Sedding <jsedding@g
> > > > > > > > mail.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 <ieb@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 <oss@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 (ie
> > > > > > > > > > > b@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...i
> > > > > > > > > > > eb:
> > > > > > > > > > > upgradeToOak178?expand=1
> > > > > > > > > > > 
> > > > > > > > > > > On 11 October 2017 at 11:38, Ian Boston <ieb@tfd.
> > > > > > > > > > > co.uk> wrote:
> > > > > > > > > > > 
> > > > > > > > > > > > 
> > > > > > > > > > > > 
> > > > > > > > > > > > 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" <stefane
> > > > > > > > > > > > > > > gli@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
> > > > > > > > > > > > > > > > ton@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
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > 
> > > > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > 

Re: Depending on Oak 1.7.x

[Chetan Mehrotra <ch...@gmail.com>]

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 <ie...@tfd.co.uk> 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 <js...@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 <ie...@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 <js...@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 <ie...@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.mehrotra@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 <ie...@tfd.co.uk> wrote:
>> >> >> > Hi,
>> >> >> >
>> >> >> > On 13 October 2017 at 15:46, Julian Sedding <js...@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 <ie...@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 <os...@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 (ieb@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 <ie...@tfd.co.uk> wrote:
>> >> >> >> >>
>> >> >> >> >> >
>> >> >> >> >> >
>> >> >> >> >> > 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
>> >> >> >> >> >> > > >
>> >> >> >> >> >> > > >
>> >> >> >> >> >> > >
>> >> >> >> >> >> > >
>> >> >> >> >> >> > >
>> >> >> >> >> >>
>> >> >> >> >> >>
>> >> >> >> >> >
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >>
>> >> >>
>> >>
>>

Re: Depending on Oak 1.7.x

[Ian Boston <ie...@tfd.co.uk>]

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 <js...@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 <ie...@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 <js...@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 <ie...@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.mehrotra@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 <ie...@tfd.co.uk> wrote:
> >> >> > Hi,
> >> >> >
> >> >> > On 13 October 2017 at 15:46, Julian Sedding <js...@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 <ie...@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 <os...@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 (ieb@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 <ie...@tfd.co.uk> wrote:
> >> >> >> >>
> >> >> >> >> >
> >> >> >> >> >
> >> >> >> >> > 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
> >> >> >> >> >> > > >
> >> >> >> >> >> > > >
> >> >> >> >> >> > >
> >> >> >> >> >> > >
> >> >> >> >> >> > >
> >> >> >> >> >>
> >> >> >> >> >>
> >> >> >> >> >
> >> >> >> >>
> >> >> >> >>
> >> >> >>
> >> >>
> >>
>

Re: Depending on Oak 1.7.x

[Julian Sedding <js...@gmail.com>]

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 <ie...@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 <js...@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 <ie...@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 <ch...@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 <ie...@tfd.co.uk> wrote:
>> >> > Hi,
>> >> >
>> >> > On 13 October 2017 at 15:46, Julian Sedding <js...@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 <ie...@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 <os...@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 (ieb@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 <ie...@tfd.co.uk> wrote:
>> >> >> >>
>> >> >> >> >
>> >> >> >> >
>> >> >> >> > 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" <st...@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
>> >> >> >> >> > > >
>> >> >> >> >> > > >
>> >> >> >> >> > >
>> >> >> >> >> > >
>> >> >> >> >> > >
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >
>> >> >> >>
>> >> >> >>
>> >> >>
>> >>
>>

Re: Depending on Oak 1.7.x

[Ian Boston <ie...@tfd.co.uk>]

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 <js...@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 <ie...@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 <ch...@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 <ie...@tfd.co.uk> wrote:
> >> > Hi,
> >> >
> >> > On 13 October 2017 at 15:46, Julian Sedding <js...@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 <ie...@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 <os...@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 (ieb@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 <ie...@tfd.co.uk> wrote:
> >> >> >>
> >> >> >> >
> >> >> >> >
> >> >> >> > 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" <st...@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
> >> >> >> >> > > >
> >> >> >> >> > > >
> >> >> >> >> > >
> >> >> >> >> > >
> >> >> >> >> > >
> >> >> >> >>
> >> >> >> >>
> >> >> >> >
> >> >> >>
> >> >> >>
> >> >>
> >>
>

Re: Depending on Oak 1.7.x

[Julian Sedding <js...@gmail.com>]

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 <ie...@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 <ch...@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 <ie...@tfd.co.uk> wrote:
>> > Hi,
>> >
>> > On 13 October 2017 at 15:46, Julian Sedding <js...@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 <ie...@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 <os...@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 (ieb@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 <ie...@tfd.co.uk> wrote:
>> >> >>
>> >> >> >
>> >> >> >
>> >> >> > On 11 October 2017 at 11:25, Robert Munteanu <ro...@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" <st...@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
>> >> >> >> > > >
>> >> >> >> > > >
>> >> >> >> > >
>> >> >> >> > >
>> >> >> >> > >
>> >> >> >>
>> >> >> >>
>> >> >> >
>> >> >>
>> >> >>
>> >>
>>

Re: Depending on Oak 1.7.x

[Ian Boston <ie...@tfd.co.uk>]

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 <ch...@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 <ie...@tfd.co.uk> wrote:
> > Hi,
> >
> > On 13 October 2017 at 15:46, Julian Sedding <js...@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 <ie...@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 <os...@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 (ieb@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 <ie...@tfd.co.uk> wrote:
> >> >>
> >> >> >
> >> >> >
> >> >> > On 11 October 2017 at 11:25, Robert Munteanu <ro...@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" <st...@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
> >> >> >> > > >
> >> >> >> > > >
> >> >> >> > >
> >> >> >> > >
> >> >> >> > >
> >> >> >>
> >> >> >>
> >> >> >
> >> >>
> >> >>
> >>
>

Re: Depending on Oak 1.7.x

[Chetan Mehrotra <ch...@gmail.com>]

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 <ie...@tfd.co.uk> wrote:
> Hi,
>
> On 13 October 2017 at 15:46, Julian Sedding <js...@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 <ie...@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 <os...@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 (ieb@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 <ie...@tfd.co.uk> wrote:
>> >>
>> >> >
>> >> >
>> >> > On 11 October 2017 at 11:25, Robert Munteanu <ro...@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 <st...@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" <st...@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
>> >> >> > > >
>> >> >> > > >
>> >> >> > >
>> >> >> > >
>> >> >> > >
>> >> >>
>> >> >>
>> >> >
>> >>
>> >>
>>

Re: Depending on Oak 1.7.x

[Ian Boston <ie...@tfd.co.uk>]

Hi,

On 13 October 2017 at 15:46, Julian Sedding <js...@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 <ie...@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 <os...@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 (ieb@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 <ie...@tfd.co.uk> wrote:
> >>
> >> >
> >> >
> >> > On 11 October 2017 at 11:25, Robert Munteanu <ro...@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 <st...@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" <st...@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
> >> >> > > >
> >> >> > > >
> >> >> > >
> >> >> > >
> >> >> > >
> >> >>
> >> >>
> >> >
> >>
> >>
>

Re: Depending on Oak 1.7.x

[Julian Sedding <js...@gmail.com>]

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.

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 <ie...@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 <os...@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 (ieb@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 <ie...@tfd.co.uk> wrote:
>>
>> >
>> >
>> > On 11 October 2017 at 11:25, Robert Munteanu <ro...@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 <st...@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" <st...@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
>> >> > > >
>> >> > > >
>> >> > >
>> >> > >
>> >> > >
>> >>
>> >>
>> >
>>
>>

Re: Depending on Oak 1.7.x

[Ian Boston <ie...@tfd.co.uk>]

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 <os...@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 (ieb@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 <ie...@tfd.co.uk> wrote:
>
> >
> >
> > On 11 October 2017 at 11:25, Robert Munteanu <ro...@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 <st...@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" <st...@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
> >> > > >
> >> > > >
> >> > >
> >> > >
> >> > >
> >>
> >>
> >
>
>

Re: Depending on Oak 1.7.x

[Matt Ryan <os...@mvryan.org>]

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 (ieb@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 <ie...@tfd.co.uk> wrote:

>
>
> On 11 October 2017 at 11:25, Robert Munteanu <ro...@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 <st...@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" <st...@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
>> > > >
>> > > >
>> > >
>> > >
>> > >
>>
>>
>

Re: Depending on Oak 1.7.x

[Ian Boston <ie...@tfd.co.uk>]

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 <ie...@tfd.co.uk> wrote:

>
>
> On 11 October 2017 at 11:25, Robert Munteanu <ro...@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 <st...@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" <st...@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
>> > > >
>> > > >
>> > >
>> > >
>> > >
>>
>>
>

Re: Depending on Oak 1.7.x

[Ian Boston <ie...@tfd.co.uk>]

On 11 October 2017 at 11:25, Robert Munteanu <ro...@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 <st...@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" <st...@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
> > > >
> > > >
> > >
> > >
> > >
>
>

Re: Depending on Oak 1.7.x

[Robert Munteanu <ro...@apache.org>]

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 <st...@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" <st...@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
> > > 
> > > 
> > 
> > 
> > 

Re: Depending on Oak 1.7.x

[Ian Boston <ie...@tfd.co.uk>]

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.
Best Regards
Ian

On 11 October 2017 at 11:07, Stefan Egli <st...@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" <st...@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
> >
> >
>
>
>

Re: Depending on Oak 1.7.x

[Stefan Egli <st...@apache.org>]

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" <st...@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
>
>

Re: Depending on Oak 1.7.x

[Stefan Egli <st...@apache.org>]

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