[
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
>
