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