Bnd based OSGi manifests

[whatnick]

Switched over from hand coded manifests to bnd based manifests. Output jar is named jna_osgi.jar but this can be tweaked if necessary.

[twall]

I don't think there's any reason to have a separate jar file, it's not like the OSGI stuff would get in the way.

On Jul 8, 2011, at 8:12 AM, whatnick wrote:

Switched over from hand coded manifests to bnd based manifests. Output jar is named jna_osgi.jar but this can be tweaked if necessary.

Reply to this email directly or view it on GitHub:
#8

[whatnick]

Feel free to reorganise the targets as you see fit, it is just some strings in the manifest. Bnd provides more complete metadata and moves the manifest key-value pairs out of the ant file. Another thing to maintain across versions, but not so hard.

[twall]

How does it provide "more complete metadata"?

On Jul 8, 2011, at 9:21 AM, whatnick wrote:

Feel free to reorganise the targets as you see fit, it is just some strings in the manifest. Bnd provides more complete metadata and moves the manifest key-value pairs out of the ant file. Another thing to maintain across versions, but not so hard.

Reply to this email directly or view it on GitHub:
#8 (comment)

[whatnick]

Bnd instructions format is here: http://www.aqute.biz/Bnd/Format . One of the nice things about it is the package dependency analysis and automatic Export of all packages. The current Ant manifest instructions do not produce valid export-package instructions (the wildcard is used wrongly). The OSGi containers do not recognise the jar as a valid bundle. Using bnd avoids such mistakes in hand coding, if the manifest generation instructions passed to Bnd are invalid it will complain.

[dblock]

I am also very confused by this. The way I read is is that jna.jar manifest is not OSGi-zed properly. Given that I doubt that anyobody actually cares what they are in the current jna.jar, why aren't you trying to modify the current ant script to do "the right thing" to jna.jar (and platform.jar)?

[whatnick]

I should add a review of what I did (I did modify the ant script). I have added

• bnd.jar under lib (this includes an ant plugin to analyze contents of a jar and produce correct manifest entries for Import-Package, Export-Package), I use the wrap ant task defined in bnd.jar
• jna.bnd , this is a configuration file bnd reads to add extra niceties like a human readable package name
• Changes to the build.xml to attach the wrap task defined in bnd.jar and a post process target on the jna.jar to inject more entries into the manifest. I removed the hand written OSGi manifest entries.

I hope this clarifies some of the questions. I am trying to stick to the existing build system while automating the OSGi manifest entry generation which is sensitive to the contents of the jar and can be hard to get right statically in the ant jar manifest tag.

[ghost]

I agree with earlier posts that creating two jars is not needed. I've seen many projects where the default shipped jar now contains OSGi information and it is handy to have to reduce confusion and external library usage, especially when transitioning to an OSGi runtime environment (Is that too obvious that this is my use case? ;) )

Also - Here are some know working values for operating systems missing the example sited above

for Solaris - osname=sunos
for Sparc architectures - processor=sparc OR processor=sparcv9

[twall]

Extended Bundle-NativeCode to cover all native implementations included in dist/jna.jar, and fixed Export-Package.