sling-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Sedding <jsedd...@gmail.com>
Subject Re: Depending on Oak 1.7.x
Date Tue, 17 Oct 2017 06:27:40 GMT
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 <ieb@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 <jsedding@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 <ieb@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 <ieb@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.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 <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
(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 <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" <stefanegli@apache.org
>> >
>> >> >> wrote:
>> >> >> >> >> >> > >
>> >> >> >> >> >> > > > Hi Ian,
>> >> >> >> >> >> > > >
>> >> >> >> >> >> > > > I don't see a problem
with having a dependency on an
>> >> >> unstable
>> >> >> >> Oak
>> >> >> >> >> >> > > > 1.7.x in
>> >> >> >> >> >> > > > Sling.
>> >> >> >> >> >> > > >
>> >> >> >> >> >> > > > Actual deployments can
still, independent of this,
>> make a
>> >> >> call
>> >> >> >> >> >> > > > whether or
>> >> >> >> >> >> > > > not they want to actually
run on Oak 1.7.x or wait for
>> >> Oak
>> >> >> 1.8
>> >> >> >> >> >> > > > (which is
>> >> >> >> >> >> > > > advisable). IMO having
this dependency doesn't imply
>> on
>> >> >> which
>> >> >> >> >> >> > > > version it
>> >> >> >> >> >> > > > will ultimately run.
>> >> >> >> >> >> > > >
>> >> >> >> >> >> > > > Cheers,
>> >> >> >> >> >> > > > Stefan
>> >> >> >> >> >> > > >
>> >> >> >> >> >> > > > On 11/10/17 11:54, "Ian
Boston" <ianboston@gmail.com
>> on
>> >> >> behalf
>> >> >> >> >> of
>> >> >> >> >> >> > > > ieb@tfd.co.uk> wrote:
>> >> >> >> >> >> > > >
>> >> >> >> >> >> > > > > Hi,
>> >> >> >> >> >> > > > > Oak 1.7.x is Oak
unstable release branch working
>> >> towards
>> >> >> 1.8.
>> >> >> >> >> >> > > > > I have a feature
in SLING-7140 that is blocked by an
>> >> API
>> >> >> >> change
>> >> >> >> >> >> > > > > in Oak
>> >> >> >> >> >> > > > > present in 1.8-SNAPSHOT
and available as an unmerged
>> >> but
>> >> >> >> tested
>> >> >> >> >> >> > > > > patch to
>> >> >> >> >> >> > > > > Oak 1.6.x.
>> >> >> >> >> >> > > > >
>> >> >> >> >> >> > > > > The Oak team are
unwilling merge the patch to 1.6
>> and
>> >> have
>> >> >> >> >> >> > > > > asked that
>> >> >> >> >> >> > > > > Sling
>> >> >> >> >> >> > > > > depend on the latest
release of Oak 1.7.
>> >> >> >> >> >> > > > >
>> >> >> >> >> >> > > > > How does the Sling
team feel about this ?
>> >> >> >> >> >> > > > >
>> >> >> >> >> >> > > > > The patch for SLING-7140
cant be merged until the
>> API
>> >> is
>> >> >> >> >> >> > > > > available in Oak
>> >> >> >> >> >> > > > > in some form and
I don't want to depend on Oak
>> >> >> 1.8-SNAPSHOT
>> >> >> >> as
>> >> >> >> >> >> > > > > this will
>> >> >> >> >> >> > > > > block Sling releases
of the bundles involved.
>> >> >> >> >> >> > > > > Best Regards
>> >> >> >> >> >> > > > > Ian
>> >> >> >> >> >> > > >
>> >> >> >> >> >> > > >
>> >> >> >> >> >> > >
>> >> >> >> >> >> > >
>> >> >> >> >> >> > >
>> >> >> >> >> >>
>> >> >> >> >> >>
>> >> >> >> >> >
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >>
>> >> >>
>> >>
>>

Mime
View raw message