IMHO spec is enough.
RegardsJB
Sent from my Samsung device
-------- Original message --------
From: Christian Schneider <ch...@die-schneider.net>
Date: 26/05/2015 07:40 (GMT+01:00)
To: users@felix.apache.org
Subject: Re: Core and Compendium APIS at runtime
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
