karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <ch...@die-schneider.net>
Subject Re: [DISCUSS] Bundle granularity (was Re: [VOTE] Release Apache Karaf version 3.0.0.RC1)
Date Wed, 13 Mar 2013 10:32:26 GMT
I have experienced some problems when libs were embedded in bundles:

When the bundle is a separate project from the original jar that does 
not embed the lib then the maven dependencies can not be used to create 
the feature.
So in the feature you have to use the bundle but exclude its 
dependencies so the feature does not additionally contain the original 
jar and the lib jar.

When the bundle that embeds the lib is the original project. Then the 
jar is not very suitable for usage outside osgi. You will easily get the 
same package from several jars.

Sometimes I also got strange classloading problems when a lib is 
embedded by several bundles.

So while in an ideal world OSGi dependency resolution based on pure 
packages should work with bundles embedding libs I thnk it is not such a 
good idea.


On 13.03.2013 11:21, Guillaume Nodet wrote:
> Starting a new thread for discussing those points.
> The idea for OSGi is modularity, but it should be done at the right level.
>   And modularity is different from code sharing.
> In OSGi, the main idea is to have bundles exposing API and services.
>   That's the way we leverage the most of OSGi.
> Unlike projects like CXF or Camel, we develop for OSGi so we should try to
> use it in the best way.
> Let's consider the 3 different things we can have in OSGi : apis,
> implementations and libraries.
> We have basic rules:
>    * service api packages should be exported
>    * service implementation packages should be kept private
> When a service bundle ships the api in the same bundle as the
> implementation, the rule is to export and import the api package to let the
> framework use package substitution if needed.   For libraries, the rule is
> to export the packages and not import those, as subsitution should never
> occur.
> One first case is service api and implementations.  A service bundle can
> either provide its own API or the API be provided by a separate package.
>   With the osgi compendium jar, it's recommended to not use it because it
> breaks modularity: this bundle provides lots of different service apis, so
> you can't change them one by one.  That's why osgi service implementation
> usually ship their own API.   For apis we control, things are slightly
> different, as we don't have those big bundles.  For those cases, the best
> thing is actually to ship the API and the service implementation in
> different bundles.  This allows updating the service implementation without
> requiring a refresh of the other bundles.
> Let's now discuss the bundle lifecycle pov.  If a bundle providing a
> service depends for the implementation on libraries packages provided by
> external bundles, it breaks the abstraction and modularity to some degree
> by exposing internal constraints.  Those constraints are better captured by
> service dependencies.
> Let's take an example: we have bundle A and B depending on a library
> provided by bundle C.  If you want to update C to provide a fix needed for
> A, this will also impact B, which could cause a regression to B
> functionality.  There are transient ways around that: i.e. deploy a new
> version of bundle C or update C and only refresh A.  But those are only
> transient as in felix, the wiring isn't retained across restarts.  And this
> can't really be controlled well with the tools we have at hand.
> On the other hand, if both bundle A and B embeds the C library needed you
> can update A and B independently, so a better modularity at the cost of
> less code sharing.
> So in an ideal OSGi world, service APIs would be shipped in individual
> bundles, and service implementation would have no other constraints than on
> other services.
> We're not in an ideal world though.  For big projects such as Camel, CXF,
> ActiveMQ, there's not always a real API and other constraints may come in,
> mostly that they are not architected purely for OSGi.
> Anyway, for small library bundles that can easily be embedded, I think we
> should do it: there's no drawbacks I can see, and it improves modularity.
> On Wed, Mar 13, 2013 at 10:05 AM, Christian Schneider <
> chris@die-schneider.net> wrote:

Christian Schneider

Open Source Architect

View raw message