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 14:47:55 GMT
Optional packages are only resolved while doing a refresh, 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.
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 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

Guillaume Nodet
Open Source SOA

View raw message