karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Baptiste Onofré ...@nanthrax.net>
Subject Re: [Discuss] Join the modules bundle, feature, config, package, system, dump into one module framework?
Date Fri, 23 Mar 2012 12:42:48 GMT
+1 with Guillaume.

I'm not against, but I don't see a huge value.

The key point is to have maximum granularity (even if we have bundle 
which contains only one interface) because it provides a more flexible 
way to create associated features.

Regards
JB

On 03/23/2012 01:20 PM, Guillaume Nodet wrote:
> 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
>>
>>
>
>

-- 
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Mime
View raw message