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] Bundle granularity (was Re: [VOTE] Release Apache Karaf version 3.0.0.RC1)
Date Wed, 13 Mar 2013 16:36:05 GMT
On Wed, Mar 13, 2013 at 4:57 PM, Jean-Baptiste Onofré <jb@nanthrax.net>wrote:

> I'm not sure to follow you.
>
> For API, I'm agree with you. For instance, the Properties (now in Felix
> Utils) case is a good example: different bundles use "Karaf" Properties,
> and so we embed the API.
>
> Now, if Karaf utils may "exposes" a set of services that different other
> bundles use: in that case, it will be an atomic bundle (but the name Utils
> is probably not the best one ;)).
>
> All depends what we put in Karaf Utils.
>

Definitely, I was referring to the current situtation which is only a set
of utility classes, no real services or apis.


>
> Regards
> JB
>
>
> On 03/13/2013 04:35 PM, Guillaume Nodet wrote:
>
>> Actually, I think I was not really clear.
>> What I mean is that the larger util is, the less it makes sense to make it
>> a bundle, because the more it breaks any kind of modularity by becoming a
>> dependency of more and more bundles.
>> The more often a bundle is used as a dependency, the more stable it should
>> be (which is what an api package is), which is the exact opposite of a
>> utility library which tends to grow over time.
>>
>>
>> On Wed, Mar 13, 2013 at 4:28 PM, Guillaume Nodet <gnodet@gmail.com>
>> wrote:
>>
>>
>>>
>>>
>>> On Wed, Mar 13, 2013 at 4:25 PM, Jean-Baptiste Onofré <jb@nanthrax.net
>>> >wrote:
>>>
>>>  I think it makes sense if utils is "larger". Currently, the coverage is
>>>> so low that I think it's a overhead.
>>>>
>>>>
>>>>  I disagree.  If utils becomes bigger, and maybe it should to avoid
>>> duplication of code throughout karaf, bundles can easily embed only the
>>> packages they use.  It's really just a matter of not using
>>> org.apache.karaf.util.* but org.apache.karaf.util.xxx in the definition
>>> of
>>> the private package.
>>>
>>>
>>>  On the other hand, I'm pretty sure that some more code can be moved into
>>>> utils ;)
>>>>
>>>> Regards
>>>> JB
>>>>
>>>>
>>>> On 03/13/2013 04:21 PM, Christian Schneider wrote:
>>>>
>>>>  Honestly I would prefer utils to be a bundle but it is also ok like it
>>>>> is.
>>>>>
>>>>> Christian
>>>>>
>>>>> On 13.03.2013 16:19, Jean-Baptiste Onofré wrote:
>>>>>
>>>>>  No Christian, don't take my wrong: I mean that sometime all (and I
>>>>>> include myself in all) we think that we do something simpler, more
>>>>>> elegant, but for the others, it's not ;)
>>>>>>
>>>>>> Karaf utils is a good example I think.
>>>>>>
>>>>>> Regards
>>>>>> JB
>>>>>>
>>>>>> On 03/13/2013 04:16 PM, Christian Schneider wrote:
>>>>>>
>>>>>>  On 13.03.2013 16:01, Jean-Baptiste Onofré wrote:
>>>>>>>
>>>>>>>
>>>>>>>> I think that on trunk we made some progress in the way that
you
>>>>>>>> describe. For instance, unlike that we have in Karaf 2.x,
modules on
>>>>>>>> trunk are structured like this:
>>>>>>>> - core provide OSGi services
>>>>>>>> - commands use the core services
>>>>>>>> - MBeans use the core services
>>>>>>>> - an end-user can use core services if he wants
>>>>>>>>
>>>>>>>>   Fortunately trunk is a little simpler already:
>>>>>>>>
>>>>>>> - core contains OSGi services and mbeans (the mbeans are only
>>>>>>> registered
>>>>>>> as osgi services)
>>>>>>> - commands contains the commands and uses the core services
>>>>>>>
>>>>>>> This simplification is an example of how we can reduce the number
of
>>>>>>> modules without sacrificing maintainability. We might need an
>>>>>>> improved
>>>>>>> aries jmx where an admin can switch on and off jmx mbeans but
apart
>>>>>>> from
>>>>>>> this I think the structure is fine.
>>>>>>>
>>>>>>>   I'm not fully agree with Christian. OSGi doesn't mean that
we have
>>>>>>> to
>>>>>>>
>>>>>>>> expose all as OSGi, for instance, it doesn't make sense for
Karaf
>>>>>>>> utils (we are not in a developer bullshit approach where
we turn all
>>>>>>>> in OSGi just for "fun" or "elegance", we have to keep things
simple,
>>>>>>>> maintainable, and coherent).
>>>>>>>>
>>>>>>>>  I hope you do not really mean to say my opinion is a "developer
>>>>>>> bullshit
>>>>>>> aproach". My main focus is exactly to keep things simple,
>>>>>>> maintainable
>>>>>>> and coherent. Just more from a developer point of view than an
admin
>>>>>>> point of view.
>>>>>>>
>>>>>>> Christian
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>  --
>>>> Jean-Baptiste Onofré
>>>> jbonofre@apache.org
>>>> http://blog.nanthrax.net
>>>> Talend - http://www.talend.com
>>>>
>>>>
>>>
>>>
>>> --
>>> ------------------------
>>> Guillaume Nodet
>>> ------------------------
>>> Red Hat, Open Source Integration
>>>
>>> Email: gnodet@redhat.com
>>> Web: http://fusesource.com
>>> Blog: http://gnodet.blogspot.com/
>>>
>>>
>>>
>>
>>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>



-- 
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration

Email: gnodet@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/

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