If there are no further comments, I am gonna merge https://github.com/apache/jackrabbit-oak/pull/1015 end of next week. Konrad
> On 10. Jul 2023, at 10:14, Konrad Windszus <[email protected]> wrote: > > Hi Marcel, > > >> On 10. Jul 2023, at 09:06, Marcel Reutegger <[email protected]> >> wrote: >> >> Hi Konrad >> >> On 03.07.23, 13:27, "Konrad Windszus" <[email protected]> wrote: >>> I would recommend to require at least OSGi R7 for Oak (released in 2018) >>> and at the same time no longer use the aggregate dependency but rather >>> the individual chapter dependencies of OSGi separately [3] which are >>> (from Compendium) >>> - Configuration Admin 1.6 >>> - Declarative Services 1.4 >>> - Metatype Service 1.4 >>> >>> Does anything speak against raising the dependencies accordingly? >> >> Does this require any code changes? I vaguely remember an earlier attempt >> to update OSGi configuration related code throughout the project, which >> required many changes and could introduced subtle changes in behaviour if >> not done correctly. > > No it doesn’t require code changes (except for maybe adding some explicit > cast to resolve ambiguous method calls. See the PR at > https://github.com/apache/jackrabbit-oak/pull/1015. > You are probably referring to https://issues.apache.org/jira/browse/OAK-6741 > which is different from this approach, as this is only about updating to a > newer version (of the same APIs/Specs) not migrating. >> >>> Is there any known consumer still relying on Oak in an OSGi container >>> which is not at least R7 compliant? >> >> Can you provide more details how this manifests? Thanks. > Sure. > As usual newer dependencies lead to import-package headers with version > ranges starting with the newer version as lower bound > (https://bnd.bndtools.org/chapters/170-versioning.html#import-version-policy) > In addition for OSGi Declarative Services there are capabilities being added > to the Manifest which require DS 1.4 or newer > (https://docs.osgi.org/specification/osgi.cmpn/7.0.0/service.component.html#service.component-capabilities) > Both lead to the fact that bundles do not start any longer in OSGi containers > not providing the necessary OSGi specifications in at least the given version. > > Hope this clarifies things, > Konrad >> >> Regards >> Marcel
