On Jan 31, 2008 3:01 PM, Peter Kriens <[EMAIL PROTECTED]> wrote: > > It's useless to add a "uses" directive for > > packages that are in the same bundle. > It is also harmless ... Besides, the important issue is that it lists > private packages, which is not wrong but useless. > > > At > > Eclipse-Orbit, we've found problems with "uses" > > and decided to no longer use it. > Well, Equinox seems to have problems with large sets of bundles. It > should be trivial to remove the extraneous uses before the resolver > uses them. Apache Felix seems to do ok as far as I know? I think not > putting the uses: directive in there is the wrong way around. It is > then better to ignore them in Equinox, I think there is a flag for this. > > > I guess that these should perhaps really be bug > > reports against the Bnd utility which autogenerated > > the Manifest; Tool: Bnd-0.0.227. > It is not a bug but a new feature. At the request of Stuart Mcculloch > I have added the following features to bnd 0.0.236
Would it be possible to add bnd 0.0.236 to the maven repo so I can try out these new features with Felix's bundle plugin? http://repo1.maven.org/maven2/biz/aQute/bndlib/ Niall > - A -nouses: true/false clause > - A possibility to set a uses: directive on an Export-Package or - > exportcontents instruction > - All uses are now filtered by the export + imports of a bundle. > > > 2. Import-Package: org.apache.commons.net.smtp > > this is also wrong though less destructive. > > commons.net.smtp is really exported and not imported. > Bnd automatically imports all exports to allow substitutability. If > you do not do this, you create all kinds of standalone class spaces > and things will not work together. It is generally bad practice to > only export a package. > > Kind regards, > > Peter Kriens > > > > On 31 jan 2008, at 14:52, Oberhuber, Martin 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. > > > > 2. Import-Package: org.apache.commons.net.smtp > > this is also wrong though less destructive. > > commons.net.smtp is really exported and not imported. > > > > 3. Export-Package: > > org > > .apache.commons.net.smtp;uses:="org.apache.commons.net.io,org.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. > > > > I guess that these should perhaps really be bug > > reports against the Bnd utility which autogenerated > > the Manifest; Tool: Bnd-0.0.227. > > > > 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. > > > > 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] > >> > >> > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
