felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Baptiste Onofré ...@nanthrax.net>
Subject Re: Core and Compendium APIS at runtime
Date Tue, 26 May 2015 12:21:57 GMT

IMHO spec is enough.

Sent from my Samsung device

-------- Original message --------
From: Christian Schneider <chris@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: 


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 
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message