aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <>
Subject Re: [DISCUSSION] The nature of uber bundles.
Date Mon, 06 Dec 2010 13:34:19 GMT
On Mon, Dec 6, 2010 at 14:23, Alasdair Nottingham <> wrote:
> On 6 December 2010 11:30, Guillaume Nodet <> wrote:
>> What I really fear is that i don't want to impact blueprint and have
>> all blueprint bundles to be re-extended because the blueprint extender
>> has been refreshed without any real need as a side effect of upgrading
>> the util module for another aries component.
> This wouldn't happen by magic though. Someone would have to do refresh packages
> to cause blueprint to be reresolved, and then only if the util/proxy
> bundle was uninstalled.
> So while I understand the concern it isn't going to happen by magic,
> someone would have
> to perform an explicit action.

Yes, of course, but my meaning is that if you want to leverage OSGi,
you need to have somewhat cohesive bundle.  if you don't, you can't
update one component without affecting the others.  In that case, if
you want to update the util package to fix a bug in one component, all
aries components would be affected, and as a consequence, all deployed
applications using aries.  So I agree, there is a user action
(refreshing the bundles), but minimizing the impact is important imho,
else, you can simply restart the whole framework, and we loose a good
chunk of features provided by osgi.

>> I'm more worried about
>> the runtime behavior of those components than a few wasted kilobytes
>> of memory.
> It isn't just the wasted kilobytes that worry me, but the additional
> complexity involved
> when consuming multiple components.
>> #1 is just a convenience as the bundle has some dependencies anyway
>> (so it just remove a few of them),
> I agree.
>> while #2 actually has an impact on
>> the runtime I think.
> I'm not sure I follow your comment here. I think #2 has the lesser
> impact on runtime
> because it contains all its dependencies.

I meant that the fact that the bundle is more cohesive and has no
external dependencies may have an impact on the way you manage the
bundles in your runtime as to minimize the impact when updating

Particularly for utils, which is a utility bundle which may grow over
time, the cohesiveness is quite low.  The problem is a bit different
for proxy as it has a clear api and uses osgi services (as to wether
this is a good idea or not is a different topic).  I personally think
the util bundle should not even be a bundle but a plain jar so as to
force each bundle to include the packages it uses and make the bundle
more cohesive.   Over time, the number of utility classes in that
bundle can grow and drag optional dependencies.   If you install a new
component which needs such a package, you need to refresh the bundle,
leading to restart all blueprint powered applications.

>> On Mon, Dec 6, 2010 at 12:05, Alasdair Nottingham <> wrote:
>>> I really want a number 1. I pull all of the aries modules into my
>>> product and currently I get multiple copies of util, and I have
>>> multiple versions of ASM.
>>> I know I could go with the individual bundles too, but this has it's
>>> own negatives, such as having a huge number of extra bundles.
>>> I understand the need for #2, but I strongly believe we should have a
>>> #1 and certainly when we first discussed uber bundles I was expecting
>>> more of a #1 than a #2.
>>> Alasdair
>>> On 6 December 2010 11:00, Guillaume Nodet <> wrote:
>>>> I'm not really sure about #1.  My main use case is more for #2 where
>>>> i'd want a standalone and highly cohesive bundle.
>>>> In all cases, i agree we should rationalize what we currently have.
>>>> On Mon, Dec 6, 2010 at 11:57, Alasdair Nottingham <>
>>>>> Hi,
>>>>> While I was working on making the proxy code common between blueprint
>>>>> and JNDI I noticed that many of our components have a *-bundle module,
>>>>> to build an "uber" bundle, but we seem to have slightly different ways
>>>>> of building these bundles. We seem to build uber bundles in one of
>>>>> three ways:
>>>>> 1. The uber bundle contains all the other modules in the same top level
>>>>> 2. The uber bundle pulls in some subset of other top level models
>>>>> (e.g. proxy and blueprint pull in the util bundle)
>>>>> 3. The uber bundle pulls in all mandatory dependencies (e.g. blueprint
>>>>> pulls in asm).
>>>>> I think it would make sense to have a common approach and as a result
>>>>> I would like to propose the following:
>>>>> 1. The uber bundle. This bundle collects all the relevant child
>>>>> modules of the module. An uber bundle does not collect other modules
>>>>> like proxy or util. Such a bundle is not standalone. So a blueprint
>>>>> uber bundle would collect blueprint-api, blueprint-core, blueprint-cm,
>>>>> but not util or proxy. A proxy uber bundle collects proxy-api,
>>>>> proxy-impl.
>>>>> 2. The nodeps bundle. This is a truely standalone bundle that includes
>>>>> everything it needs. It is standalone. So the blueprint nodeps bundle
>>>>> would pull in the util, proxy modules and asm.
>>>>> I think this balances the desire for ease of deployment with the
>>>>> desire for better sharing and modularity and minimum duplication of
>>>>> code.
>>>>> What do people think?
>>>>> Thanks
>>>>> Alasdair
>>>>> --
>>>>> Alasdair Nottingham
>>>> --
>>>> Cheers,
>>>> Guillaume Nodet
>>>> ------------------------
>>>> Blog:
>>>> ------------------------
>>>> Open Source SOA
>>> --
>>> Alasdair Nottingham
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog:
>> ------------------------
>> Open Source SOA
> --
> Alasdair Nottingham

Guillaume Nodet
Open Source SOA

View raw message