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/ > > -- ------------------------ Guillaume Nodet ------------------------ Red Hat, Open Source Integration Email: gno...@redhat.com Web: http://fusesource.com Blog: http://gnodet.blogspot.com/
