Multiple parent feature versions

[Konrad Baczynski <ko...@empirica.io>]

Hello,

I am doing provisioning via features.

Let's assume you have one parent features repository and two child 
repositories that have defined the parent one. Every child repository 
has one feature which depends on the same feature in the parent repository.

You upgraded one bundle version in the feature in the parent repository. 
You upgraded the parent version in the first child repository, but you 
didn't do it for the other one.

Then you added both child repositories, when you install both features 
from child repositories, you have two versions of the bundle from the 
feature from the parent repository. Is there a possibility to cope with 
it? Since the versions were backward compatible, you would like to have 
only one version.


Best regards

Konrad Bączyński

-- 
Konrad Bączyński
Software developer
konrad.baczynski@empirica.io

Empirica Sp. z o.o.
ul. Curie-Skłodowskiej 12
50-381 Wrocław

www.empirica.pl
  
NIP 8982201370, REGON 021955151

Zarejestrowana w Sądzie Rejonowym dla Wrocławia-Fabrycznej, VI Wydział Gospodarczy Krajowego Rejestru Sądowego pod numerem KRS 0000914199. Kapitał zakładowy: 650.000,00 zł opłacony w całości.

Re: Multiple parent feature versions

[Łukasz Dywicki <lu...@code-house.org>]

Hey Konrad,
There are few ways you can avoid issue:
1) Use version ranges for features
2) Use version ranges for bundles
3) Override versions in custom assembly

Case 1 and 2 allow you to import feature sets independently of each 
other. Version range usually aims highest version within range, so you 
can move within specified limit ie. 0.x or 0.0.x. Yet, one thing to 
remember is that version ranges are handled differently at feature 
element (then it's OSGi version range) and at feature/bundle URI (then 
it's Maven version range). Both works mostly fine, but for Maven version 
3.0-SNAPSHOT (alpha, beta as well) is outside of 3.0 range while for 
OSGi it is within the bound as SNAPSHOT is just an qualifier.
For third option you can centrally adjust which version to go with, 
simply overriding versions used in both feature sets. Obviously it is 
not as handy as first two, as it requires you to control a third file, 
yet it gives you a complete control over everything. I use it ie. to 
force specific versions of netty or jetty across third party feature 
sets I sometimes use.
A compact example of how to achieve that based on pax/log4j 2.x issue 
from last year: https://github.com/openhab/openhab-distro/pull/1350/files

Powodzenia! :)
Łukasz

On 8.06.2022 09:17, Konrad Baczynski wrote:
> Hello,
> 
> I am doing provisioning via features.
> 
> Let's assume you have one parent features repository and two child 
> repositories that have defined the parent one. Every child repository 
> has one feature which depends on the same feature in the parent repository.
> 
> You upgraded one bundle version in the feature in the parent repository. 
> You upgraded the parent version in the first child repository, but you 
> didn't do it for the other one.
> 
> Then you added both child repositories, when you install both features 
> from child repositories, you have two versions of the bundle from the 
> feature from the parent repository. Is there a possibility to cope with 
> it? Since the versions were backward compatible, you would like to have 
> only one version.
> 
> 
> Best regards
> 
> Konrad Bączyński
>