Do you also have best practices for clients?
I think in most cases it makes sense that a client just imports a the
spec package.
What about the case where a client optionally depends on a spec package?
One case I saw several times was an optional dependency on the event
admin. The problem with this is that if the provider of the package is
not present when the bundle installs it will not see it. Karaf 4 will
provide a mechanism to rewire a bundle with optional packages once they
are resolveable but this also can lead to cascades of restarts.
So does it make sense for the case of clients with an optional
dependency on an API package to embed and import/export it?
One thing that could go wrong with this is that client and provider of
the API might bind to different versions of the package. So I am not sure.
One such case where we currently discuss about this is:
https://issues.apache.org/jira/browse/KARAF-3739
Christian
Am 25.05.2015 um 09:38 schrieb Peter Kriens:
This kind of reasoning is often caused by not seeing the extremely tight
relation between the provider of an API and that API itself. There is virtually
no backward compatibility for providers, if the API changes, you need a new
provider. Separating the provider from its API therefore just creates a lot of
work and potential error cases that provide no benefit whatsoever.
The best practice I learned over time is therefore is that a provider includes
an exact copy of the API package that it is build against and both exports AND
imports it. Since OSGi packages have a globally unique name + version this
works, the framework will share one of the exported packages if possible. This
model has a number of advantages:
1) The resolver can automatically drag in implementations based on the API
2) You have significantly fewer bundles to worry about
3) You always have the right version at hand
4) bnd supports this model very well with its package include from class path
function and calculation of importing exports.
Every time I run into bundles that do not include their API I get this
desperate sinking feeling :-(
The idea that it works better with multiple providers of the same API is
nonsense since they both MUST use the identical versions of the overlapping
packages. That is, there is no backward compatibility to speak of for
providers. So substitutable imports work fine for this use case.
The only argument for separating API and implementation in two bundles is that
you do not have to refresh the client if you update an implementation. True,
but due to transitive dependencies it takes real hard work to actually achieve
this unless you have a small trivial system. And an OSGi system that can handle
the going down of any bundle is likely not very valuable since it will likely
fail. So realistically, this argument sounds nice in theory but has very little
value in practice.
Interestingly, this discussion was held early on and several times thereafter.
Initially, I was not sure, the separate API bundle did not sound so bad. Now,
15 years later I am quite convinced that the provider including the API is the
best solution in most cases.
Kind regards,
Peter Kriens
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
