tuscany-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Sebastien Delfino <jsdelf...@apache.org>
Subject Re: Improving support for running in OSGi
Date Thu, 01 May 2008 18:07:42 GMT
Simon Laws wrote:
> On Thu, May 1, 2008 at 1:00 PM, Graham Charters <gcharters@googlemail.com>
> wrote:
> 
>> It would seem that the fine-grained/coarse-grained thoughts have
>> people divided.  Rajini's note (aside from the fact she has a tonne of
>> experience having done most, if not all, of the OSGi work in Tuscany)
>> paints a picture where the two are not mutually exclusive.  I don't
>> typically like doing two options because that seems like indecision,
>> but in this case they do appear to complement each other.
>>
>> Based on what I've seen in this thread, I'm hoping this briefly
>> summarizes the collection of thoughts on how we might proceed:
>>
>> Tuscany Running in OSGi
>>
>> 1.  Add bundle manifests to all the Tuscany modules (using maven
>> bundle plugin).  This will ensure the most fine-grained decomposition
>> works and therefore coarser-grained distributions will also work.
>> 2.  Add a distribution which creates bundles around manageable
>> collections of Tuscany modules aligned with how we see the runtime
>> being extended/subsetted/replaced.  Have this build and test on
>> Continuum.
>> 3.  Create 'virtual bundles' for third-party libraries to avoid
>> licensing and disk space issues (based on Rajini's suggestions, which
>> I need to better understand).
>> 4.  Provide guidance on the wiki on how to avoid breaking OSGi.
>>
>> There's also the suggestion that implementation.osgi relate to
>> Distributed OSGi (RFC 119), which shouldn't be lost.
>>
>> Have I missed anything?
>>
>> It sounds like a staging of 1 & 3 first, followed by 2 would work (and
>> 4 if things keep breaking :-( ).  I'd be concerned if we didn't get to
>> 2, and as part of 1&3, we need to make sure these are regularly tested
>> under osgi.
>>
>>
>> 2008/5/1 Mike Edwards <mike.edwards.inglenook@gmail.com>:
>>> Simon Laws wrote:
>>>
>>>> On Thu, May 1, 2008 at 10:03 AM, Rajini Sivaram <
>>>> rajinisivaram@googlemail.com> wrote:
>>>>
>>>>
>>>>> On 5/1/08, Jean-Sebastien Delfino <jsdelfino@apache.org> wrote:
>>>>>
>>>>>> My 2c:
>>>>>>
>>>>>> +1 to promote OSGi to a first class Tuscany runtime environment
>>>>>>
>>>>>> +1 for an OSGi continuum build (thinking about a build profile
>> that'll
>>>>> run
>>>>>
>>>>>> the Tuscany itest suite in an OSGi environment, similar to the
>>> profiles
>>>>> we
>>>>>
>>>>>> have for Web containers for example)
>>>>>>
>>>>>> Here's what I imagined we'd do:
>>>>>> 1. add OSGi entries to each of our JAR manifests
>>>>>> 2. have developers maintain them and pay attention to
>> imports/exports
>>>>>> 3. use the OSGi build to detect API and SPI import/export
>> violations
>>>>>> 4. find the best way to OSGi-enable 3rd party dependency JARs
>>>>>>
>>>>>> I realize that my suggestion [1] is not very popular and most
>> people
>>> on
>>>>>> this list would prefer to come up with bigger bundles grouping
>> several
>>>>> of
>>>>>
>>>>>> our JARs/modules. I don't think that the 'bigger aggregate bundle'
>>>>>>
>>>>> approach
>>>>>
>>>>>> will work, but I'll be happy to watch people try it :) if they
>>  want
>>> to.
>>>>>> With respect to [4] I find rather funny to see many projects out
>> there
>>>>>> claim OSGi enablement without having OSGified their 3rd party
>>>>>>
>>>>> dependencies.
>>>>>
>>>>>> I wonder how that works, can an OSGi-enabled project really
>> leverage
>>> the
>>>>>> OSGi classloader isolation and versioning capabilities when 99% of
>> the
>>>>> JARs
>>>>>
>>>>>> it requires are not OSGi bundles? I must be missing something...
>> and I
>>>>> hope
>>>>>
>>>>>> we can do better in Tuscany with a real end-to-end OSGi enablement
>>> story
>>>>> :)
>>>>>
>>>>>> --
>>>>>> Jean-Sebastien
>>>>>>
>>>>>>
>>>>> I agree with Sebastien's suggestions1-4. But I would like to suggest
>> a
>>>>> slight variation to the first suggestion.
>>>>>
>>>>>
>>>>>  1. Use maven-bundle-plugin to introduce OSGi manifest entries into
>> all
>>>>>  the Tuscany modules, with auto-generated import/export statements.
>>>>> Modify
>>>>>  itest/osgi-tuscany to run these modules under OSGi, with all 3rd
>> party
>>>>> jars
>>>>>  installed into OSGi using virtual bundles created on the fly.
>>>>>
>>>>> This step will provide a version of osgi-tuscany tests that is less
>>> prone
>>>>> to
>>>>> breakage than the one we have today. It will also help fix any
>> remaining
>>>>> classloading issues that we have left in Tuscany (and hopefully help
>>>>> in maintaining the classloader isolation). This is not a big piece
>> of
>>> work
>>>>> since this is just bringing together the different pieces that we
>>> already
>>>>> have. I will be happy to contribute the code towards this first
>> step, so
>>>>> others can concentrate on what we really want to achieve in terms of
>>>>> modularity, distribution etc. We can also use this step to explore
>>>>> versioning - in particular about having multiple extensions
>> referring to
>>>>> different versions of 3rd party libraries. This will be very useful
>> for
>>> 4.
>>>>> Suggestions 2-3 are not requirements for OSGi, but these are clearly
>>> cases
>>>>> where OSGi technology can help Tuscany improve modularity. If we
>> want to
>>>>> have explicitly hard-coded import/export statements in the modules
>> to
>>>>> enforce modularity, that can be introduced in step 2.
>>>>>
>>>>> And I would expect that there will be more work in terms of building
>> the
>>>>> distributions suitable for OSGi as well as non-OSGi after 1-4.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Thank you...
>>>>>
>>>>> Regards,
>>>>>
>>>>> Rajini
>>>>>
>>>>>
>>>> Re. modularity, it strikes me that there is lack of consensus about
>>> whether
>>>> big bundles or small bundles, relative to our maven modules,  are
>>> preferable
>>>> but that there is consensus about using OSGi bundles to help us test
>> and
>>>> refine out modularity story.
>>>>
>>>> So maybe we should agree to disregard the question about how big OSGi
>>>> bundles should be relative to our maven modules and concentrate on the
>>>> question about whether our maven modules are correctly factored. Using
>>> OSGi
>>>> as a tool to help us with this of course.
>>>>
>>>> Simon
>>>>
>>>>
>>>  I support both Rajini's and Simon's points.  We can get the mechanics
>> going
>>> first with the bundles following the existing grain of the modules - and
>> we
>>> can discuss and tinker with the modules as we please later to find the
>> best
>>> arrangements.
>>>
>>>  I suspect that the differing opinions about module size reflect
>> different
>>> usecases.  Lots of small modules can promote great flexibility in the
>>> construction of runtimes, but at the expense of making it much harder
>> for
>>> users to make sense of the options.  Larger modules cut down the options
>> but
>>> make things easier for end users.
>>>
>>>
>>>  Yours,  Mike.
>>>
> 
> I would further propose that we take a subset of the output of 1 and 3, for
> example, enough to run the calculator sample, as an initial test case
> separate from the full range of itest/osgi-tuscany tests. This would give us
> something to shoot re. inclusion in the regular build.
> 
> Simon
> 

+1 Very good idea

-- 
Jean-Sebastien

Mime
View raw message