aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alasdair Nottingham <...@apache.org>
Subject Re: [DISCUSSION] The nature of uber bundles.
Date Sun, 19 Dec 2010 11:46:57 GMT
Hi,

Based on this discussion I am going to change our <module>-bundle
modules to follow the model #1 described in my previous note.

This will remove the utils components from blueprint, but I do not
think that is a huge issue. The main concern I think might be that the
proxy support optionally imports asm, but I could make this import
required which would solve that issue. I'll also make asm a mandatory
dependency rather than optional. I'll raise a JIRA.

Thanks
Alasdair

On 19 December 2010 11:40, Alasdair Nottingham <not@apache.org> wrote:
> On reviewing this thread I realised I hadn't responded to this point email.
>
>
> On 6 December 2010 14:47, Guillaume Nodet <gnodet@gmail.com> 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 <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
>>
>
>
>
> --
> Alasdair Nottingham
> not@apache.org
>



-- 
Alasdair Nottingham
not@apache.org

Mime
View raw message