Found an fixed it in https://svn.apache.org/r1740106. Please quickly cross-check. I had to include the latest SNAPSHOT versions of all API providers from some interfaces in org.apache.sling.api.scripting in the launchpad (namely scripting core and servlet resolver). Konrad
> On 20 Apr 2016, at 11:21, Konrad Windszus <[email protected]> wrote: > > Can someone give me a pointer? To be honest I don't really know how to fix > this here and what is the real problem because I couldn't find where this > happens in the code: >>> (Currently this breaks a number of integration tests as the >>> org.apache.sling.launchpad.test-services bundle is rebuilt with a >>> version range of [2.3,3) and does not find that in the launchpad) > > I already elaborated why I think that increasing the version makes sense here. > I would love to fix the IT, but currently just don't know how. > Konrad > >> On 18 Apr 2016, at 16:00, Konrad Windszus <[email protected]> wrote: >> >> Can you elaborate why the ITs in org.apache.sling.launchpad.test-services >> bundle break because of this? >> >>> On 18 Apr 2016, at 15:22, Bertrand Delacretaz <[email protected]> >>> wrote: >>> >>> Hi, >>> >>> In https://svn.apache.org/r1739719 Konrad incremented the >>> org.apache.sling.api.scripting from 2.2.0 to 2.3.0 for SLING-5665 . >>> >>> That ticket introduces a minor semantic change in >>> SlingScriptHelper.getServices(...), sorting the returned services >>> based on their service ranking, with no binary API changes. >>> >>> It's just the semantics of the getServices method that change, in a >>> backwards compatible way. >>> >>> I think we might just change the package version to 2.2.1, meaning "no >>> backward compatibility issues" as per the OSGi semantic versioning >>> recommendations. >>> >>> WDYT? >>> >>> -Bertrand >>> >>> (Currently this breaks a number of integration tests as the >>> org.apache.sling.launchpad.test-services bundle is rebuilt with a >>> version range of [2.3,3) and does not find that in the launchpad) >> >
