On Wed, Mar 13, 2013 at 4:57 PM, Jean-Baptiste Onofré <j...@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 <gno...@gmail.com> >> wrote: >> >> >>> >>> >>> On Wed, Mar 13, 2013 at 4:25 PM, Jean-Baptiste Onofré <j...@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é >>>> jbono...@apache.org >>>> http://blog.nanthrax.net >>>> Talend - http://www.talend.com >>>> >>>> >>> >>> >>> -- >>> ------------------------ >>> Guillaume Nodet >>> ------------------------ >>> Red Hat, Open Source Integration >>> >>> Email: gno...@redhat.com >>> Web: http://fusesource.com >>> Blog: http://gnodet.blogspot.com/ >>> >>> >>> >> >> > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com > -- ------------------------ Guillaume Nodet ------------------------ Red Hat, Open Source Integration Email: gno...@redhat.com Web: http://fusesource.com Blog: http://gnodet.blogspot.com/
