If you want to prevent certain bundles or bundle versions at runtime, my instinct would be to look into resolver hooks[0] and/or bundle hooks[1]. The resolver hooks should allow preventing certain bundles from being resolved and from playing a role in the resolution of other bundles. The bundle hooks should allow preventing bundles from seeing certain other bundles.
Disclaimer: I have not experimented with these hooks yet. YMMV.
On Wed, 9 Oct 2024 at 14:02, Michael Lipp via osgi-dev <osgi-dev@xxxxxxxxxxx> wrote:
Considering the info about you on
LinkedIn, there must be something non-obvious about this question.
Let me provide a beginner's answer to
check if I got it right. There are actually two occasions during
development when you might want to blacklist bundles: during build
time and at run-time.
In both situations, the bundles
available for building (or running) are primarily controlled by
the configuration of the repository/repositories used
(https://mnlipp.github.io/osgi-getting-started/Repositories.html).
When using bnd to provide the "classpath" for building, the
configuration of the "built-in" repository providers follows a
"list of positives" approach, i.e. you explicitly specify the
bundles that should be available in your repositories (no
blacklisting required). The "Bnd POM Repository"
(https://bnd.bndtools.org/plugins/pomrepo.html) deviates from this
approach a bit, because it automatically provides additional
bundles as specified by the dependencies from the Maven POM. AFAIK
there is no possibility to blacklist individual dependencies with
this plugin. (But on the other hand side, if you cannot rely on
the defined maven dependencies, something's wrong anyway.)
My "Indexed Maven Repository plugin"
(http://mnlipp.github.io/de.mnl.osgi/IndexedMavenRepository.html)
takes the opposite approach by making everything from a maven
group available unless explicitly disabled (effectively
blacklisted). This approach should not be taken in an enterprise
context (see below), but is very convenient for small projects
that simply assume newer versions to be better.
At run-time, there may be two different
scenarios. The easy one is that you resolve all dependencies at
build time using a bndrun configuration. There you can explicitly
blacklist specific versions to prevent them from being used when
resolving your initial (explicitly required) bundles. I assume
that you have seen this before, but here
(https://github.com/mnlipp/jgrapes-osgi/blob/master/org.jgrapes.osgi.demo.console/democonsole.bndrun)
is a non-trivial bndrun file. The list of runbundles is what
results from the automatic resolution, considering whatever your
repositories provide as candidate (unless blacklisted).
The more complicated run-time situation
is when you have something like e.g. Eclipse that does its
resolution on startup. Here you have to look at the mechanism used
and find out how to configure it to blacklist something (if
possible).
While all this may seem a bit
complicated, the reasoning behind it is OSGi's approach of
separating API and implementation (it's not unique to OSGi, but
followed rather strictly in this context). So the repository used
during building should only provide the API-bundles used by your
bundle (or application) under development and every change of an
API's version should be a controlled by an explicit process. The
actual implementation of the API used at run-time is much more
dynamic. Either because you want to try another provider (e.g.
switching from Felix to Equinox) or because some version of an
implementation bundle has proven to be buggy and you want to
replace it with the fixed version (and optionally blacklist the
buggy version to make sure that it isn't used under any
circumstances).
- Michael
Am 09.10.24 um 12:08 schrieb Dr. James
J. Hunt via osgi-dev:
Dear Colleagues,
Does OSGi provide any mechanism for blacklisting particular
versions of OSGi bundles?