aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Charters <>
Subject Re: [DISCUSSION] The nature of uber bundles.
Date Mon, 06 Dec 2010 15:55:53 GMT
I think we should be creating highly cohesive modules, but cohesion
doesn't mean I happen to depend on a bundle, it's down to things like
their functional scope and lifecycle.  I don't see how we could
possibly be cohesive with a library that is provided by a completely
separate project, and I'd question the cohesion with any modules that
are simply helpful utilities.  These utilities will evolve

I recently tried to put together a demo of Apache Tuscany and Apache
Aries, where my starting point was a Tuscany Uber bundle.  This ended
up being a completely fruitless approach because of "uses" and
resource conflicts and I had to resort to using the individual
bundles.  It seems parts of this thread are trying to solve
provisioning problems by compromising the modularity.  Surely
packaging everything inside uber bundles is akin to Require-Bundle and
will essentially neuter any attempt to follow good OSGi modularity
practices of using Import/Export-Package and semantic versioning.  I
can see how the blueprint subprojects might make sense to belong in a
single bundle, since they'll likely evolve and be released together,
although I'm not even sure in that case that everyone will want all
blueprint features and blueprint is intentionally extensible for this
very reason.

On 6 December 2010 14:47, Guillaume Nodet <> wrote:
> 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
>>>>>> 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

View raw message