karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Achim Nierbeck <bcanh...@googlemail.com>
Subject Re: [Discuss] Join the modules bundle, feature, config, package, system, dump into one module framework?
Date Fri, 23 Mar 2012 12:52:02 GMT
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



-- 

Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
Committer & Project Lead
blog <http://notizblog.nierbeck.de/>

Mime
View raw message