tuscany-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Graham Charters" <gchart...@googlemail.com>
Subject Re: Improving support for running in OSGi
Date Fri, 02 May 2008 10:05:54 GMT
Hi Rajini,

FWIW, I agree with starting with 1.  I missed your earlier note saying
you'd be happy to contribute code to do this.  Please let me know what
I can do to help.  I'm particularly interested in the 'virtual bundle'
idea.  I took a look at the way the samples are run in
itest/osgi-tuscany and now I have a better understanding, I agree,
it's not as much work as I first thought (fear of the unknown ;-) ).
I think the challenge will be in finding the right design to enable it
for third-party libraries so it's usable and flexible enough.  Perhaps
you already have thoughts on this?

I was a little surprised you didn't suggest 3 as a stepping stone
towards 4 (I guess the '"half-hearted" comment was a bit of a
give-away ;-) ).  I agree it's not ideal from a modularity perspective
but it does have the advantage that I think it could be introduced a
lot sooner than 4 and would therefore accelerate sensitizing folks to
the issues.

Regards, Graham.

2008/5/2 Rajini Sivaram <rajinisivaram@googlemail.com>:
> On 5/1/08, Jean-Sebastien Delfino <jsdelfino@apache.org> wrote:
>
>
>
> > Graham Charters 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.
>  > >
>  > >
>  > Sounds good to me, with the following comments:
>  >
>  > When you have (1) + (3) you can already run a continuum OSGi build, before
>  > attacking (2). I'd actually suggest to start building on continuum as soon
>  > as we have (1).
>  >
>  > - I'm not clear on what you meant by 'use the Maven bundle plugin'. Will
>  > we write something like this for example:
>  > <project>
>  >  ...
>  >  <packaging>bundle</packaging>
>  >  ...
>  >  <plugin>
>  >    <groupId>org.apache.felix</groupId>
>  >    <artifactId>maven-bundle-plugin</artifactId>
>  >    <extensions>true</extensions>
>  >    <configuration>
>  >      <instructions>
>  >        <Export-Package>org.apache.tuscany.sca.foo</Export-Package>
>  >        <Import-Package>org.apache.tuscany.sca.bar</Import-Package>
>  >        <Private-Package>org.apache.tuscany.sca.impl.*</Private-Package>
>  >      </instructions>
>  >    </configuration>
>  >  </plugin>
>  > ...
>
>
>
>  I think we have four options on how we start bundle-izing Tuscany modules,
>  using maven-bundle-plugin.
>
>
>  1. Use the manifest goal to generate the manifest entry in all module jars,
>  with <Export-Package>*</Export-Package> and
>  <Import-Package>*</Import-Package>, which export all the packages from the
>  module and import everything used by the module. The Export-Package and
>  Import-Package statements in the generated manifest will use explicit
>  package import/exports like:
>
>  Import-Package:
>  javax.xml.namespace,javax.xml.parsers,org.apache.tuscany.sca.contribution.resolver,...
>  Export-Package:
>  org.apache.tuscany.sca.implementation.osgi;version="2.0";uses:="o.a.t.s.assembly",/...
>
>
>  The analysis of Import/Export will be done by the maven-bundle-plugin in
>  this case. The actual generation of the module jar will remain the same as
>  now, the only addition will be a new generated manifest file.
>
>  We might not use <Export-Package>*</Export-Package> , but instead it would
>  be something more like
>  <Export-Package>org.apache.tuscany.sca.implementation.osgi.*</Export-Package>,
>  where the packages are wildcarded, but no assumptions about modularity are
>  made.
>
>  2. Use bundle goal with Import/Export as above (generated by
>  maven-bundle-plugin rather than explicitly specified). In this case the jar
>  itself will be generated using maven-bundle-plugin. The output jar should be
>  identical to 1.
>
>  3. Use manifest goal with explicitly listed <Export-Package/>,
>  <Import-Package/> as in Sebastien's example. All exported and (maybe)
>  imported packages  are explicitly specified in the pom. Everytime a
>  new package is added, the pom should be updated.
>
>  4.  Use bundle goal with explicitly listed <Export-Package/>,
>  <Import-Package/> and <Private-Package/> as in Sebastien's example. This
>  option corresponds to Sebastien's example. In this case both the contents of
>  the jar, as well as the manifest are based on the explicitly listed
>  packages.
>
>
>  1. is the easiest to implement. It makes no assumptions about modularity,
>  and will not have any impact on non-OSGi applications since only the
>  manifest entry is affected. From an OSGi point of view, this gives all we
>  need for osgi-tuscany.
>
>  2. does not add any value over 1.
>
>  3. This is a half-hearted attempt to enforce modularity. osgi-tuscany will
>  break everytime someone introduces a new package  and doesn't update the
>  pom. But Tuscany will continue to operate without OSGi since only the
>  manifest is broken. 3. is not a requirement for OSGi-based Tuscany, but
>  merely the use of OSGi technology to improve modularity. osgi-tuscany will
>  take on the role on policing modularity(apart from testing that Tuscany can
>  be run in an OSGi runtime).
>
>  4. This is OSGi best practice. If a new package is introduced and the pom is
>  not updated, the jar itself will be unusable. Basically this requires all
>  developers to be OSGi-aware. The value-add of this option over 1. is the
>  enforcement of modularity, and like 3, this is not a requirement for
>  OSGi-based Tuscany. I am not sure we are ready for this yet. I think there
>  is a real risk that frequent breakages will create the perception that OSGi
>  integration is impossible to maintain, even though this is more to do with
>  enforcing modularity rather than OSGi.
>
>
>  I would like to suggest that we start with 1., use the generated manifest
>  files to understand and improve modularity and jump to 4. to enforce
>  modularity when we are ready for it.
>
>
>
>
>
>
>  > or did you mean something else?
>  >
>  > --
>  > Jean-Sebastien
>  >
>
>
>
>  --
>  Thank you...
>
>  Regards,
>
>  Rajini
>

Mime
View raw message