karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <gno...@gmail.com>
Subject Re: [Discuss] Join the modules bundle, feature, config, package, system, dump into one module framework?
Date Fri, 23 Mar 2012 12:20:42 GMT
I would tend to favor coarse grained bundles, but for a given service, i.e.
have a bundle which contain all the feature api + impl + management +
commands, same for others.

Plus, having fine grained bundles gives our users the benefit of being able
to remove some part without any difficulties, for example, if one does not
want JMX management, not installing all the management bundles is enough.

We could have an additional packaging for ease of use which would bring
into a single bundle a bunch of those, but I'm not sure who would use it.

So I'm not sure I really see the benefits in what you propose beyond
reducing the number of bundles, which I don't think is really a problem in
itself.


On Thu, Mar 22, 2012 at 13:58, Christian Schneider
<chris@die-schneider.net>wrote:

> Hi all,
>
> some day ago I created the issue below:
> https://issues.apache.org/**jira/browse/KARAF-1273<https://issues.apache.org/jira/browse/KARAF-1273>
>
> The idea is that we might be able to reduce the number of bundles
> considerably by joining several modules we have right now into one module.
> The commonality of these modules is that they are basically always loaded
> in karaf and do not draw in additional dependencies.
>
> To consolidate these is most interesting for the api (.core) and the
> service impls (.core.internal) as both are very small for each module.  I
> am less sure for the commands as there are more classes and also more
> config in the blueprint file.
>
> Some other things to discuss is the package structure and if we should
> separate an API package from the service impls.
>
> So about the package structure I see two possible designs:
>
> 1)
> org.apache.karaf.framework.**bundle.core
> org.apache.karaf.framework.**bundle.core.impl
> org.apache.karaf.framework.**service.core
> org.apache.karaf.framework.**service.core.impl
> ...
>
> 2)
>
> org.apache.karaf.bundle.core
> org.apache.karaf.bundle.core.**impl
> org.apache.karaf.service.core
> org.apache.karaf.service.core.**impl
> ...
>
> 1) Has the advantage that you see from the parent package what belongs to
> framework. The disadvantage is that we have to change the packages and are
> less felxible to separate them into bundles later if we want to.
>
> 2) Has the advantage that we do not have to change the packages and that
> we are flexible how to package them. The disadvantage is that it is less
> clear what package ends up in what jar.
>
>
> The other issue is the API module. I think it would make sense to have an
> API module that contains:
>
> org.apache.karaf.bundle.core
> org.apache.karaf.service.core
> org.apache.karaf.bundle.**management
> org.apache.karaf.service.**management
>
> That would allow users of the mbeans or services to just depend on the API
> package and not get into contact with the impl. Of course in our current
> structure the impls are hidden inside OSGi anyway but not at build time /
> in the IDE. We could further separate API and management API but I think
> this is not really necessary.
>
>
> So if we choose Variant 2 and separate out the api we would have:
>
> framework/api
>  org.apache.karaf.bundle.core
>  org.apache.karaf.service.core
>  org.apache.karaf.bundle.**management
>  org.apache.karaf.service.**management
>  ...
>
> framework/core
>  org.apache.karaf.bundle.core.**internal
>  org.apache.karaf.service.core.**internal
>  ...
>
> framework/management
>  org.apache.karaf.bundle.**management.internal
>  org.apache.karaf.service.**management.internal
>  ...
>
> framework/command
>  org.apache.karaf.bundle.**command
>  org.apache.karaf.service.**command
>  ...
>
>
> Christian
>
>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> Talend Application Integration Division http://www.talend.com
>
>


-- 
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
FuseSource, Integration everywhere
http://fusesource.com

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message