A user of Gradle complained about bnd on the bnd(tools) mailing list that turned out to be caused by the use of bnd in the Gradle OSGi plugin.
bnd need to see the resources in the target bundle, that is, they need to be in the JAR given to the analyzer. Currently it can only see the classes folder (At least that explains what I see). In this case the user used Bundle-ClassPath; this failed because bnd could not find the included JARs. However, there are many other checks done that are related to resources. At least, you should add the resources to the Jar object that you pass to the Analyzer with setJar(Jar).
bnd has VERY extensive error checking; unfortunately, looking at the source code these are completely totally utterly ignored. In general you can do analyzer.check(), if this returns true than you have a happy Analyzer. Otherwise there are errors (getErrors()). You can get the warnings (which are often quite useful) with getWarnings(). The check() method takes a list of strings that are regexps. These regexps are applied against warnings and errors, which are then subsequently removed.
You’re using an Analyzer, it would be better to use a Builder. However, in that case you should allow bnd to create the final JAR. This is more logical for bnd and there a myriad of very useful OSGi related functions that can then be used (-includeresource comes to mind). There are other functions like (conditionally) copying packages from the classpath in the bundle, something very important to make good bundles. If you use the Builder, I would use the following defaults:
-includeresource: resources, classes
For the class path, you should add your classes folder. This allows people to create proper OSG bundles by specifying the packages that should be used.This defaults make it work out of the box for your current users and allow all the added capabilities of bnd to be used. The current setup will confuse people because not all bnd’s instructions are available.
It would be very nice if there would be a possibility to see the property and the class path of the Analyzer (or Builder) before calcManifest is called. This would make debugging a lot easier
The manifest in bnd is sorted and made canonical. By copying the manifest into another Map you likely screw up this order. Again, if bnd is allowed to write the JAR this will be done correctly. It would be nice to add a header in the manifest that this manifest is not generated by bnd.
Some of the defaults are wrong:
a) Import-Package default
“, !org.apache.ant., !org.junit., !org.jmock., !org.easymock., !org.mockito.”);
This is completely arbitrary and should not be a default. On top of that, it does not work since the * will import already anything and the remainder is ignored. ! instructions should always precede the wildcard. These instructions are processed sequentially. Please, please, let bnd handle the default.
“*;-noimport:=false;version=” + getVersion());
Hmm. Where to start:
i) Modularity is about NOT exporting. Most bundles I make have no exports. So the default should never be *, it is the antithesis of modularity.
ii) If you insist, change this to -exportcontents. This is very confusing since the Builder will include the whole class path for this instruction
iii) -noimport should not be set. bnd is very clever in detecting if something does not have to be imported, if it does, there are sound reasons. You should rarely have to override bnd’s defaults.
iv) Exporting a package with the bundle’s version is wrong
v) Even if you export the package with the bundle version, you should be consistent. If the Bundle-Version instruction is set you will get a different version for the bundle and packages, which will be really confusing.
vi) Setting the version on the exports will override any version information bnd can find in the package’s packageinfo file or the annotations on package-info.java, or the manifest if bundles on the class path.
- Manifest digests calculated by bnd are not copied to the destination manifest.
Hope this helps, let me know if I can help improving this plugin further.