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

Reply via email to