I use the karaf to run an OSGI bundle which use a built-in commons-lang3.5.jar.
The problem is when I run this bundle, the karaf will auto load another commons-lang3.1.jar. I am not sure when it be load. But it take my bundle crash.
Are there any ways to uninstall the karaf default built-in bundle?
Nope, don't "uninstall" the default built-in bundle cause it is used by others. Make sure your own bundle does a clean import for the commons lang bundle.
a bnd instruction would look like:
import-package:
org.apache.commons.lang;version="[3.5,4.0)", \
*
this way you make sure you import only commons lang if there is a better version available then the one you already have included yourself.
Hint, don't embed dependencies, but make sure you depend on re-usable dependencies. With such import packages you can make sure you depend on a specific version.
As Achim says, do not uninstall the default bundle, but do specify the your required version range. However, I would recommend that you not use the normal OSGI version range, and instead specify [3.5.0,3.5.0].
At the moment, it is safest to only import COMMONS bundles using a point version, or using a version range starting with the lowest version that you have determined to be compatible with your code using bnd baseline or similar, and ending in the full version number of the version you're building against.
For example, ignoring all minor releases:
between release 3.0 and 3.1 of commons-lang, the only baseline reported api changes were minors in two packages:
org.apache.commons.lang3 and org.apache.commons.lang3.exception.
However, all packages were bumped to 3.1.0.
Between from 3.1 to 3.2, there were minor changes to several packages: a second minor level change to org.apache.commons.lang3, and initial minor changes to
org.apache.commons.lang3.reflect, org.apache.commons.lang3.text, org.apache.commons.lang3.text.translate, and org.apache.commons.lang3.tuple.
However, there was major change to org.apache.commons.lang3.time.
Again, all package versions were just set to 3.2.0 , except now instead of the package versions being overly restrictive , there is a now a concealed breaking change.
In other words: comparing the declared export package versions to more "accurate" package versions based on baseline-detected changes, we have the following.
Note that for packages with minor changes only, the "accurate" package version numbers reflects the number of releases with minor changes to that package, and not a package number of any particular release.
Package | "Accurate" | Declared ------------------------------------------------------------------ = org.apache.commons.lang3 | 3.2.0 | 3.2.0 + org.apache.commons.lang3.builder | 3.0.0 | 3.2.0 + org.apache.commons.lang3.concurrent | 3.0.0 | 3.2.0 + org.apache.commons.lang3.event | 3.0.0 | 3.2.0 + org.apache.commons.lang3.exception | 3.1.0 | 3.2.0 + org.apache.commons.lang3.math | 3.0.0 | 3.2.0 + org.apache.commons.lang3.mutable | 3.0.0 | 3.2.0 + org.apache.commons.lang3.reflect | 3.1.0 | 3.2.0 + org.apache.commons.lang3.text | 3.1.0 | 3.2.0 + org.apache.commons.lang3.text.translate| 3.1.0 | 3.2.0 * org.apache.commons.lang3.time | 4.0.0 | 3.2.0 + org.apache.commons.lang3.tuple | 3.1.0 | 3.2.0
The package number is "correct" for 1 package, too conservative for 10 packages, and wrong for 1. This remains unchanged if we follow the pattern all the way to 3.5 (with a second concealed MAJOR change to the time package between 3.4 and 3.5:
Package | "Accurate" | Declared ------------------------------------------------------------------ = org.apache.commons.lang3 | 3.5.0 | 3.5.0 + org.apache.commons.lang3.builder | 3.3.0 | 3.5.0 + org.apache.commons.lang3.concurrent | 3.1.0 | 3.5.0 + org.apache.commons.lang3.event | 3.1.0 | 3.5.0 + org.apache.commons.lang3.exception | 3.2.0 | 3.5.0 + org.apache.commons.lang3.math | 3.2.0 | 3.5.0 + org.apache.commons.lang3.mutable | 3.2.0 | 3.5.0 + org.apache.commons.lang3.reflect | 3.4.0 | 3.5.0 + org.apache.commons.lang3.text | 3.3.0 | 3.5.0 + org.apache.commons.lang3.text.translate| 3.2.0 | 3.5.0 * org.apache.commons.lang3.time | 5.0.0 | 3.5.0 + org.apache.commons.lang3.tuple | 3.1.0 | 3.5.0
[ I'm in a discussion with some of the COMMONS project people about package versions, after I opened an issue for commons-compress about OSGI version issues. For this project, every version of every package is identical to the release number (extended to three digits), and all are in the range [1,2).
The folks commons super-project are hung up about packageinfo files being in the source directory; possibly because I added a manual copy of the packageinfo files from the src tree, which apparently is not required anymore. They also would prefer that package versions should be generated automatically.
I haven't yet explained properly why the maven-bundle-plugin default of using the release version for every package is dangerous, and that changing a package version should be done by the person changing the source in way that changes the version (to avoid accidental breaking changes), with the baseline verify serving as a kind of unit test.
Ironically I submitted the changes as part of getting ready to merge in some substantive contributions to compress, which were made to help store every declared bundle from maven central, in order to analyze how reliable package version numbers are, and to see how much can be done to automatically fix them when using a database backed repository (and to see if there are any features of bundle series that are predictors of reliability). ]
