No worries ..
I was not sure myself so I asked .. I am fine with keeping it as it is.
Christian
Am 23.03.2012 13:52, schrieb Achim Nierbeck:
sorry dude,
I'm also with +1 with Guillaume and JB
I don't see a real benefit to open another construction-site here.
Don't we have enough of those already?
ever thought about YAGNI?
regards, Achim
2012/3/23 Jean-Baptiste Onofré<[email protected]>:
+1 with Guillaume.
I'm not against, but I don't see a huge value.
The key point is to have maximum granularity (even if we have bundle which
contains only one interface) because it provides a more flexible way to
create associated features.
Regards
JB
On 03/23/2012 01:20 PM, Guillaume Nodet wrote:
I would tend to favor coarse grained bundles, but for a given service,
i.e.
have a bundle which contain all the feature api + impl + management +
commands, same for others.
Plus, having fine grained bundles gives our users the benefit of being
able
to remove some part without any difficulties, for example, if one does not
want JMX management, not installing all the management bundles is enough.
We could have an additional packaging for ease of use which would bring
into a single bundle a bunch of those, but I'm not sure who would use it.
So I'm not sure I really see the benefits in what you propose beyond
reducing the number of bundles, which I don't think is really a problem in
itself.
On Thu, Mar 22, 2012 at 13:58, Christian Schneider
<[email protected]>wrote:
Hi all,
some day ago I created the issue below:
https://issues.apache.org/**jira/browse/KARAF-1273<https://issues.apache.org/jira/browse/KARAF-1273>
The idea is that we might be able to reduce the number of bundles
considerably by joining several modules we have right now into one
module.
The commonality of these modules is that they are basically always loaded
in karaf and do not draw in additional dependencies.
To consolidate these is most interesting for the api (.core) and the
service impls (.core.internal) as both are very small for each module. I
am less sure for the commands as there are more classes and also more
config in the blueprint file.
Some other things to discuss is the package structure and if we should
separate an API package from the service impls.
So about the package structure I see two possible designs:
1)
org.apache.karaf.framework.**bundle.core
org.apache.karaf.framework.**bundle.core.impl
org.apache.karaf.framework.**service.core
org.apache.karaf.framework.**service.core.impl
...
2)
org.apache.karaf.bundle.core
org.apache.karaf.bundle.core.**impl
org.apache.karaf.service.core
org.apache.karaf.service.core.**impl
...
1) Has the advantage that you see from the parent package what belongs to
framework. The disadvantage is that we have to change the packages and
are
less felxible to separate them into bundles later if we want to.
2) Has the advantage that we do not have to change the packages and that
we are flexible how to package them. The disadvantage is that it is less
clear what package ends up in what jar.
The other issue is the API module. I think it would make sense to have an
API module that contains:
org.apache.karaf.bundle.core
org.apache.karaf.service.core
org.apache.karaf.bundle.**management
org.apache.karaf.service.**management
That would allow users of the mbeans or services to just depend on the
API
package and not get into contact with the impl. Of course in our current
structure the impls are hidden inside OSGi anyway but not at build time /
in the IDE. We could further separate API and management API but I think
this is not really necessary.
So if we choose Variant 2 and separate out the api we would have:
framework/api
org.apache.karaf.bundle.core
org.apache.karaf.service.core
org.apache.karaf.bundle.**management
org.apache.karaf.service.**management
...
framework/core
org.apache.karaf.bundle.core.**internal
org.apache.karaf.service.core.**internal
...
framework/management
org.apache.karaf.bundle.**management.internal
org.apache.karaf.service.**management.internal
...
framework/command
org.apache.karaf.bundle.**command
org.apache.karaf.service.**command
...
Christian
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
--
Jean-Baptiste Onofré
[email protected]
http://blog.nanthrax.net
Talend - http://www.talend.com
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
