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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf > Of Stuart McCulloch > Sent: Donnerstag, 31. Jänner 2008 16:53 > To: [EMAIL PROTECTED] > Cc: Jakarta Commons Developers List; Orbit Developer discussion > Subject: Re: Support for OSGi > > On 31/01/2008, Oberhuber, Martin > <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] > > > Sent: Tuesday, January 29, 2008 11:30 PM > > > To: Commons Developers List > > > Cc: [EMAIL PROTECTED] > > > 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 > > > <[EMAIL PROTECTED]> 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 > > > > [EMAIL PROTECTED] > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > -- > Cheers, Stuart > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
