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] Join the modules bundle, feature, config, package, system, dump into one module framework?
Date Fri, 23 Mar 2012 14:16:18 GMT
No worries ..

I was not sure myself so I asked .. I am fine with keeping it as it is.

Christian

Am 23.03.2012 13:52, schrieb Achim Nierbeck:
> sorry dude,
>
> I'm also with +1 with Guillaume and JB
> I don't see a real benefit to open another construction-site here.
> Don't we have enough of those already?
>
> ever thought about YAGNI?
>
> regards, Achim
>
> 2012/3/23 Jean-Baptiste Onofré<jb@nanthrax.net>:
>> +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
>
>


-- 
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
Talend Application Integration Division http://www.talend.com


Mime
View raw message