Re: Depending on Oak 1.7.x

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

Re: Depending on Oak 1.7.x

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 >

Re: Depending on Oak 1.7.x

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

Re: Depending on Oak 1.7.x

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

Re: Depending on Oak 1.7.x

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

Re: Depending on Oak 1.7.x

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 wrote: > Hi Ian > > The only bundle with a direct dependency to Oak is Sling JCR Resource. > All other bundles you mention

Re: Depending on Oak 1.7.x

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

Re: Depending on Oak 1.7.x

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

Re: Depending on Oak 1.7.x

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

Re: Depending on Oak 1.7.x

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

Re: Depending on Oak 1.7.x

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

Re: Depending on Oak 1.7.x

Hi, On 13 October 2017 at 15:46, Julian Sedding 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

Re: Depending on Oak 1.7.x

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

Re: Depending on Oak 1.7.x

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

Re: Depending on Oak 1.7.x

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

Re: Depending on Oak 1.7.x

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

Re: Depending on Oak 1.7.x

On 11 October 2017 at 11:25, Robert Munteanu 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

Re: Depending on Oak 1.7.x

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

Re: Depending on Oak 1.7.x

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 >

Re: Depending on Oak 1.7.x

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

Re: Depending on Oak 1.7.x

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

Re: Depending on Oak 1.7.x

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,

Re: Depending on Oak 1.7.x

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

Depending on Oak 1.7.x

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