OK, catcha ;)
Thanks
Regards
JB
On 03/13/2013 05:36 PM, Guillaume Nodet wrote:
On Wed, Mar 13, 2013 at 4:57 PM, Jean-Baptiste Onofré 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
On Wed, Mar 13, 2013 at 4:57 PM, Jean-Baptiste Onofré 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 "
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
I don't think that the number of bundles is an issue: if the user uses
bundle:list (without -t 0), he doesn't see that ;)
For instance, in some projects, like ACE or Aries, we have a lot of
bundles, and it's not a big deal.
Regards
JB
On 03/13/2013 04:26 PM, Guillaume Nodet wrote:
On Wed, M
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 sho
On 13.03.2013 16:26, Guillaume Nodet wrote:
On Wed, Mar 13, 2013 at 4:01 PM, Jean-Baptiste Onofré wrote:
Thanks Guillaume for this remember (or introduction for some of us I think
;)).
I think that on trunk we made some progress in the way that you describe.
For instance, unlike that we have i
On Wed, Mar 13, 2013 at 4:25 PM, Jean-Baptiste Onofré 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 eas
On Wed, Mar 13, 2013 at 4:01 PM, Jean-Baptiste Onofré wrote:
> Thanks Guillaume for this remember (or introduction for some of us I think
> ;)).
>
> 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
> st
I think it makes sense if utils is "larger". Currently, the coverage is
so low that I think it's a overhead.
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
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 other
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
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
Thanks Guillaume for this remember (or introduction for some of us I
think ;)).
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
Ah, and one additional thing I haven't mentioned is the use of optional
imports, especially for libraries. It makes modularity much more
complicated as any kind of resolver will need additional input to know if
those imports should be satisfied or not, and it also disturbs existing
bundles during
The more complex the wiring is, the largest the number of potential issues.
Let's keep things as simple as possible.
Moreover, I find the large number of bundles, as a result of unwinding libs
intimidating to the new users.
--
*Ioannis Canellos*
*
**
Blog: http://iocanel.blogspot.com
**
Twitter
On Wed, Mar 13, 2013 at 12:16 PM, Christian Schneider <
ch...@die-schneider.net> wrote:
> Another problem is that at least eclipse + m2e does not cope very well
> with provided scope and embedded bundles.
>
> So for example I still can not have the karaf console project open in
> eclipse. As soon
Another problem is that at least eclipse + m2e does not cope very well
with provided scope and embedded bundles.
So for example I still can not have the karaf console project open in
eclipse. As soon as I open it all projects depending on the console
are flagged as broken as they do not see th
On Wed, Mar 13, 2013 at 11:32 AM, Christian Schneider <
ch...@die-schneider.net> wrote:
> I have experienced some problems when libs were embedded in bundles:
>
> When the bundle is a separate project from the original jar that does not
> embed the lib then the maven dependencies can not be used t
I have experienced some problems when libs were embedded in bundles:
When the bundle is a separate project from the original jar that does
not embed the lib then the maven dependencies can not be used to create
the feature.
So in the feature you have to use the bundle but exclude its
dependenc
Starting a new thread for discussing those points.
The idea for OSGi is modularity, but it should be done at the right level.
And modularity is different from code sharing.
In OSGi, the main idea is to have bundles exposing API and services.
That's the way we leverage the most of OSGi.
Unlike p
20 matches
Mail list logo
