Hi, I recently had a discussion with BJ around that in https://github.com/osgi/osgi/issues/452. His opinion was that one should always depend on the minimum version providing the necessary API, which kind of makes sense, but also is more effort to manage for our huge amount of bundles. According to him depending on R7 versions for all relevant spec chapters (or on R8, R6) unnecessarily limits the usability of those bundles in arbitrary OSGi containers.
I agree with that statement, but I still think we should still manage one (reasonable old, in our case R7) version of the individual spec dependency in our parent. Every module can easily overwrite that locally with newer versions (older versions are IMHO right now not required, I never read bug reports due to incompatibility with very old OSGi containers). Konrad > On 1. Jul 2022, at 09:42, Robert Munteanu <[email protected]> wrote: > > Hi, > > We are managing the individual OSGi artifact versions in the parent > pom, which is very convenient. We are currently targeting OSGi R7 with > the parent pom. I assume at some point we would want to switch to R8 > and will therefore upgrade the dependencies. > > I was wondering whether it made sense to expose the desired OSGi spec > version through a property, e.g. sling.osgi.version, and then allow > bundles to specify whether they want to target version 7, 8, or > something else. > > Thoughts? > Robert
