BndTools generated package version issues?

GENERAL
1

A listing of the bundles in question

g! lb | grep fueling

457|Active | 1|org.syntech.fueling.api.enterprise (3.0.1)|3.0.1
459|Installed | 1|org.syntech.fueling.enterprise.dao.jpa (5.0.0)|5.0.0

Ok so 459 needs started, it should of started already but ok.

g! start 459

g! org.osgi.framework.BundleException: Unable to resolve org.syntech.fueling.enterprise.dao.jpa [459](R 459.0): missing requirement [org.syntech.fueling.enterprise.dao.jpa [459](R 459.0)] osgi.wiring.package; (&(osgi.wiring.package=org.syntech.fueling.api.model)(version>=2.0.0)(!(version>=3.0.0))) Unresolved requirements: [[org.syntech.fueling.enterprise.dao.jpa [459](R 459.0)] osgi.wiring.package; (&(osgi.wiring.package=org.syntech.fueling.api.model)(version>=2.0.0)(!(version>=3.0.0)))]

That’s weird it appears it is saying it needs org.syntech.fueling.api.model <= version 3.0.0 but we are not using package version just bundle versioning. Let me check what my bundle is exporting.

g! headers 457
org.syntech.fueling.api.enterprise (457)
----------------------------------------
Bundle-Copyright = Copyright (C) Syntech (2021). All Rights Reserved.
Bundle-ManifestVersion = 2
Bundle-Name = org.syntech.fueling.api.enterprise
Bundle-SymbolicName = org.syntech.fueling.api.enterprise
Bundle-Vendor = Syntech
Bundle-Version = 3.0.1
Export-Package = org.syntech.fueling.api.enterprise;uses:="com.fasterxml.jackson.annotation,org.syntech.core.api.util.common,org.syntech.fueling.api.model,org.syntech.tank.api.enterprise";version="3.0.1",org.syntech.fueling.api.sync;version="1.0.0";uses:="com.fasterxml.jackson.annotation,org.syntech.core.api.util.common,org.syntech.fueling.api.model",org.syntech.fueling.api.model;version="3.0.1",org.syntech.fueling.api.enterprise.dao;uses:="org.syntech.fueling.api.enterprise,org.syntech.fueling.api.model";version="3.0.1"

Git-Descriptor = 9.23.1-3122-g3c89470ed6-dirty
Git-SHA = 3c89470ed64a62ff7385d21c2ae3d41244e8fe76

Import-Package = com.fasterxml.jackson.annotation;version="[2.11,3)",org.apache.commons.lang3.builder;version="[3.9,4)",org.syntech.core.api.util.common;version="[2.9,3)",org.syntech.fueling.api.enterprise,org.syntech.fueling.api.model,org.syntech.tank.api.enterprise;version="[7.1,8)"

Manifest-Version = 1.0

Require-Capability = osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.8))"

Tool = Bnd-4.3.1.201911131708

Seems to me the generated package version requirements are off. I have seen this from time to time and gotten past it by jostling things, but this one is being persistent. Any ideas.

2

It might help to show what your setup is? I.e. maven poms or bnd files.

3

@pkriens thanks for the reply. Though we use gradle for our builds for CI and production I only recall ever seeing this issue when running from the ide (using either BndTools in eclipse or the Amdatu plugin for Intellij). We use bnd files for bundle definition and don’t typically version our packages with packageinfo.java files, though there are a couple around.

4

bnd picks up the import version during build, based on the bundle that is on the classpath at the time. So it looks to me that when you build, the org.syntech.fueling.enterprise.dao.jpa bundle was build with a previous version of the org.syntech.fueling.api.enterprise bundle on the class path.

I expect that you are getting yourself in this mess because you avoid package versions :slight_smile:

It is good to see you’re using an API bundle. However, if you’re using the Bundle version for the package, and you create major version jumps, you basically are not using one of the most powerful aspects of OSGi. In my experience, then people use versions ad hoc, which creates more work and misery than just keeping everything at version 1.0.

I’d suggest you actually add & properly maintain package versions, this likely prevents the problems you’re seeing except when there is really a problem with compatibility. Which was the design intent of versions. If you add baselining to your build you will find that it requires very little effort to maintain package versions and you’d be surprised how often you tend to make changes that are not backward compatible.

1 Like