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.
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
