aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alasdair Nottingham <>
Subject Re: [DISCUSSION] The nature of uber bundles.
Date Sun, 19 Dec 2010 11:40:55 GMT
On reviewing this thread I realised I hadn't responded to this point email.

On 6 December 2010 14:47, Guillaume Nodet <> wrote:
> Optional packages are only resolved while doing a refresh,
This is not true. Optional packages are resolved when the bundle is
installed, if the package is missing then the import will be dropped
and a refresh is required to pick it up. This means their is a
possible ordering constraint when installing bundles

so if I have
>   A  imports a package from B
>   install bundle C which provide an optional package for B
>   install bundle D which uses that optional package
> In order for D to see the correct package wiring, bundle B needs to be
> refreshed, which afaik makes the old wiring goes away, meaning C will
> be refreshed too.

I don't really follow your example. bundle D can only use packages it
imports. I assume you mean bundle D uses a capability provided by
bundle C only if package B is wired? In any case I believe your
scenario would result in the correct resolution with some frameworks
such as equinox which resolve bundles as a group. A smart provisioner
should be able to detect it is installing  A, B, C and D and install
them in the right order. If C were installed a long time after A and B
then I think this is just what you get.

> The same is true for fragments btw.
> Updating a bundle does actually have no effect on existing wirings
> though.  I'm wondering if doing the following would work:
>  * install C
>  * update B (without any actual change)
>  * install D
>  * resolve D
> Not sure if D would actually get a version of B with the correct wiring.
> On Mon, Dec 6, 2010 at 15:32, Jeremy Hughes <> 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.  I'm more worried about
>> Why would you have to refresh the blueprint extender? If you install a
>> new version of the util bundle, Blueprint can carry on using the old
>> one while other bundles use the new one - as long as you pass the
>> right bundles into refreshPackages. Surely? What am I missing?
>>> the runtime behavior of those components than a few wasted kilobytes
>>> of memory.
>>> #1 is just a convenience as the bundle has some dependencies anyway
>>> (so it just remove a few of them), while #2 actually has an impact on
>>> the runtime I think.
>>> 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
>>>>>> 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 module
>>>>>> 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
>>>>>> 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
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog:
> ------------------------
> Open Source SOA

Alasdair Nottingham

View raw message