Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[orbit-dev] RE: Support for OSGi

Hello Niall / Stuart,

thanks for your answers. It looks like the usage patterns
of OSGi in the Apache and Eclipse communities are just 
a bit different: Apache focuses on packages whereas Eclipse
focuses on Bundle granularity for Re-use.

That's why we don't explicitly import all exported packages
at Eclipse -- we're using Require-Bundle instead of 
Import-Package throughout our system, mostly due to the way
Eclipse Plugins have been workign in the past. For details,
see also 

http://dev.eclipse.org/mhonarc/lists/orbit-dev/msg00627.html

What does that mean in practice?

1.) Looks like we Eclipse folk will need to continue writing
    our own OSGi Manifests for some time since the 
    "Require-Bundle" vs. "Import-Package" patterns do not
    mix too well.

2.) Whenever somebody converts an auto-generated OSGi Manifest 
    into a manually maintained one, it's worth thinking about
    a) What packages are really API and thus worth being 
       exported, versus what packages are considered internal
       hidden implementation;
    b) What packages are expected to be potentially split
       across multiple bundles, or would always reside inside
       the same bundle.

Or am I missing something?

Thanks,
--
Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm
 
 

> -----Original Message-----
> From: mcculls@xxxxxxxxx [mailto:mcculls@xxxxxxxxx] On Behalf 
> Of Stuart McCulloch
> Sent: Donnerstag, 31. Jänner 2008 16:53
> To: dev@xxxxxxxxxxxxxxxx
> Cc: Jakarta Commons Developers List; Orbit Developer discussion
> Subject: Re: Support for OSGi
> 
> On 31/01/2008, Oberhuber, Martin 
> <Martin.Oberhuber@xxxxxxxxxxxxx> wrote:
> >
> > Hello Niall,
> >
> > it would be interesting for Eclipse consumers as
> > well to get Apache bundles with Meta-info already
> > applied.
> >
> > Currently, the Meta-info is mostly added manually
> > as part of the Eclipse Orbit project.
> >
> > I have had a brief look at your auto-generated
> > MANIFEST for commons net, and found a few issues:
> >
> > 
> http://people.apache.org/~niallp/commons-osgi/commons-net-1.5.
> 0-SNAPSHOT
> > -MANIFEST.MF
> >
> > 1. Import-Package: examples;version="1.5.0.SNAPSHOT"
> >    this is just wrong. The commons net deliverable
> >    jar should not import examples.
> 
> 
> I assume there's an examples package somewhere (or something 
> pulls in the
> examples package)
> You can explicitly ask Bnd to remove/ignore this import by 
> using !examples
> in the Import-Package
> if you know that you won't actually need it during runtime (ie. it's
> dead/unused code)
> 
> eg:   <Import-Package>!examples,*</Import-Package>
> 
> 2. Import-Package: org.apache.commons.net.smtp
> >    this is also wrong though less destructive.
> >    commons.net.smtp is really exported and not imported.
> 
> 
> Actually this is correct - it's good practice to import your 
> exports as it
> ensures a consistent class
> space and avoids problems when upgrading bundles. Otherwise 
> you *will* run
> into casting issues.
> 
> 3. Export-Package:
> > 
> org.apache.commons.net.smtp;uses:="org.apache.commons.net.io,o
> rg.apache.
> > commons.net"
> >    It's useless to add a "uses" directive for
> >    packages that are in the same bundle. At
> >    Eclipse-Orbit, we've found problems with "uses"
> >    and decided to no longer use it.
> 
> 
> As Peter says, he's recently updated Bnd to give users more 
> control over
> "uses" and improved
> the default generation. BTW, there is a good reason for the 
> "uses" clause as
> explained by Glyn:
> 
> 
> http://underlap.blogspot.com/2007/10/osgi-type-safety-and-uses
> -directive.html
> 
> I haven't seen any problem with "uses" on Felix, but I guess 
> Equinox could
> always add an option
> to ignore it - as there are likely to be other bundles out 
> there that have
> "uses" in their manifest.
> 
> I guess that these should perhaps really be bug
> > reports against the Bnd utility which autogenerated
> > the Manifest; Tool: Bnd-0.0.227.
> 
> 
> The elimination of "uses" is really a new feature, and the imports of
> exports is not a bug - the
> only bug (as such) is the appearance of the "examples" 
> package, but I'd need
> to see the final
> jar to understand why Bnd detected it (ie. it may be a 
> justified import
> based on the content)
> 
> But for me, it also shows that in the current stage
> > it looks like the OSGi manifest still needs to be
> > written by hand and not auto-generated.
> 
> 
> From experience I'd argue it's the other way round - OSGi 
> manifests should
> be auto-generated.
> But, as with any tool, you should verify it yourself and add 
> any customized
> attributes and minor
> adjustments.
> 
> Otherwise you'll have to manually keep the manifest in step 
> with your code,
> and it's amazingly
> easy to miss imports when they're buried inside the code, 
> which is why such
> tools are needed.
> 
> The other benefit of auto-generation is you can do it 
> dynamically - for
> example, at OPS4J we
> have a deployment tool that lets you load third-party jars which
> automatically get turned into
> OSGi bundles. This really helps with rapid prototyping (great 
> if you have a
> legacy jar, but don't
> know the code well enough to craft an OSGi manifest yourself)
> 
> Anyways, if there is a plan to make a downloadable
> > release of any commons packages with OSGi info
> > added, I'd like to know.
> >
> > Thanks,
> > --
> > Martin Oberhuber, Senior Member of Technical Staff, Wind River
> > Target Management Project Lead, DSDP PMC Member
> > http://www.eclipse.org/dsdp/tm
> >
> >
> >
> > > -----Original Message-----
> > > From: Niall Pemberton [mailto:niall.pemberton@xxxxxxxxx]
> > > Sent: Tuesday, January 29, 2008 11:30 PM
> > > To: Commons Developers List
> > > Cc: dev@xxxxxxxxxxxxxxxx
> > > Subject: Re: Support for OSGi
> > >
> > > I have created a JIRA ticket for the changes to the 
> commons-parent pom
> > > to add the bundle plugin:
> > >   https://issues.apache.org/jira/browse/COMMONSSITE-23
> > >
> > > I have also tested out the plugin by generating the 
> jars/manifest for
> > > all but three components:
> > >   http://people.apache.org/~niallp/commons-osgi/
> > >
> > > I'll leave the ticket open for a few days - but unless there are
> > > objections/issues raised I plan to apply the changes to
> > > commons-parent.
> > >
> > > Niall
> > >
> > > On Dec 19, 2007 2:38 PM, Carsten Ziegeler
> > > <cziegeler@xxxxxxxxxx> wrote:
> > > > Hi,
> > > >
> > > > the products of commons are highly used throughout many 
> projects.
> > > >
> > > > It would be great, if the projects here at Apche 
> Commons could help
> > > > those projects that are using OSGi.
> > > >
> > > > OSGi is based around the concept of a bundle - a bundle is
> > > a jar file
> > > > with additional meta data like the packages it exports 
> and a list of
> > > > external packages it is using (please forgive me if I'm
> > > simplifying here
> > > > too much).
> > > >
> > > > As many projects are using artifacts from Apache Commons,
> > > they need the
> > > > specific jars as bundles. This is most often done by
> > > creating so called
> > > > wrapper bundles: these are jars that have the same 
> contents as the
> > > > original library with the addition of the required meta data.
> > > > You can find several examples here:
> > > >
> > > > http://svn.apache.org/repos/asf/felix/trunk/commons/
> > > >
> > > > Now, it would be great, if the projects here at Apache 
> Commons would
> > > > already provide artifacs that can be directly used in an
> > > OSGi environment.
> > > >
> > > > All that has to be done is adding some entries to the
> > > manifest. This is
> > > > usually a list of imported packages, a list of exported 
> packages, a
> > > > symbolic name for the bundle and a version. (There are 
> some more but
> > > > these are the most important ones).
> > > >
> > > > Adding these entries can be done by hand (not recommended)
> > > or with tools
> > > > automatically. For example the Apache Felix maven
> > > bundleplugin requires
> > > > just some lines of configuration and that's it.
> > > >
> > > > It would be great if some of the projects here could add
> > > these meta data
> > > > as part of their next release. This will make the life of
> > > all projects
> > > > using OSGi much much easier.
> > > >
> > > > So if you're interested in helping us, just let us 
> know. We would be
> > > > happy to make the required changes to the poms or whatever
> > > needs to be
> > > > done. I cc'ed the Felix dev list as some Felix developers
> > > might not be
> > > > subscribed to the commons dev list, so please keep them
> > > cross posted.
> > > >
> > > > Thanks
> > > > Carsten
> > > > --
> > > > Carsten Ziegeler
> > > > cziegeler@xxxxxxxxxx
> > > >
> > > >
> > > 
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxx
> > > > For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxx
> > > >
> > > >
> > >
> > > 
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxx
> > > For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxx
> > >
> > >
> >
> 
> 
> 
> -- 
> Cheers, Stuart
> 


Back to the top