karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <ch...@die-schneider.net>
Subject [Discuss] Join the modules bundle, feature, config, package, system, dump into one module framework?
Date Thu, 22 Mar 2012 12:58:57 GMT
Hi all,

some day ago I created the issue below:
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


Mime
View raw message