[RT] Decoupling the OSGi spec version from the parent version

[Robert Munteanu <ro...@apache.org>]

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

Re: [RT] Decoupling the OSGi spec version from the parent version

[Robert Munteanu <ro...@apache.org>]

On Fri, 2022-07-01 at 09:53 +0200, Konrad Windszus wrote:
> 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).

+1, that makes pefect sense to me.

Thanks,
Robert

Re: [RT] Decoupling the OSGi spec version from the parent version

[Konrad Windszus <kw...@apache.org>]

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 <ro...@apache.org> 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