aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Bosschaert <david.bosscha...@gmail.com>
Subject Re: [DISCUSSION] The nature of uber bundles.
Date Mon, 06 Dec 2010 16:10:02 GMT
I have been working with an uber bundle (more like #3 above) with the
CXF-DOSGi subproject which provides two distributions, the
single-bundle distro (#3) and a multi-bundle distro.

Although the single-bundle distro has proven very handy if you want to
get started quickly (e.g. for educational purposes) it has proven to
be if limited use in real applications, so I'd like to echo Graham's
concerns. In nearly every case where the single bundle distro had to
be combined with another OSGi subsystem it caused issues. The real
problem that needs to be solved is the provisioning problem. I think
in the end that small, focused, cohesive bundles are the most reusable
in varying contexts. Yes you will have many bundles, and this might be
an issue for deployment, but let's solve that problem separately.

Cheers,

David

On 6 December 2010 15:55, Graham Charters <gcharters@gmail.com> wrote:
> 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
> independently.
>
> 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 <gnodet@gmail.com> 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 <hughesj@apache.org> wrote:
>>> On 6 December 2010 11:30, Guillaume Nodet <gnodet@gmail.com> 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 <not@apache.org>
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 <gnodet@gmail.com> 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 <not@apache.org>
wrote:
>>>>>>> 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 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
of
>>>>>>> code.
>>>>>>>
>>>>>>> What do people think?
>>>>>>> Thanks
>>>>>>> Alasdair
>>>>>>>
>>>>>>> --
>>>>>>> Alasdair Nottingham
>>>>>>> not@apache.org
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Cheers,
>>>>>> Guillaume Nodet
>>>>>> ------------------------
>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>> ------------------------
>>>>>> Open Source SOA
>>>>>> http://fusesource.com
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Alasdair Nottingham
>>>>> not@apache.org
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Cheers,
>>>> Guillaume Nodet
>>>> ------------------------
>>>> Blog: http://gnodet.blogspot.com/
>>>> ------------------------
>>>> Open Source SOA
>>>> http://fusesource.com
>>>>
>>>
>>
>>
>>
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
>>
>

Mime
View raw message