[Discuss] Join the modules bundle, feature, config, package, system, dump into one module framework?

[cschneider]

Hi all,

some day ago I created the issue below:
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

[iocanel]

Hi Christian,

From, the list of the modules you described only framework and system are
"always" installed. For example the minimal distribution starts none of the
rest.

Besides that, I don't feel that there is need to reduce the number of Karaf
bundles per se.

--
*Ioannis Canellos*
*
FuseSource <http://fusesource.com>

**
Blog: http://iocanel.blogspot.com
**
Twitter: iocanel
*

[Guillaume Nodet]

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
<[hidden email]>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
>
>

--
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
FuseSource, Integration everywhere
http://fusesource.com

[cschneider]

Am 23.03.2012 13:20, schrieb Guillaume Nodet:
> 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.
I think at least API should be separate as it allows people to e.g. use
the mbeans remotely without having to know anything about their impl. So
I propose we either create one
API bundle for the modules I wrote or one for each module.
>
> 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.
I still would have the management bundle as that is not always installed.
>
> 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.
I am also not sure if the benefit of having less projects and less
bundles is worth it.

Christian

--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
Talend Application Integration Division http://www.talend.com

[jbonofre]

+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
> <[hidden email]>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é
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com

[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é <[hidden email]>:

> +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
>> <[hidden email]>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é
> [hidden email]
> http://blog.nanthrax.net
> Talend - http://www.talend.com

--

Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
Committer & Project Lead
blog <http://notizblog.nierbeck.de/>

[cschneider]

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é<[hidden email]>:
>> +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
>>> <[hidden email]>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é
>> [hidden email]
>> 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