Using Bnd's Verifier class from Gradle

[Chris Rankin]

Hi,

I have a mission to verify that the OSGi meta-data in the bundle manifest accurately describes the bundle's contents. In particular, that every package listed in Export-Package is available somewhere along the bundle's Bundle-ClassPath. This is important because Bnd's Resolve task does not detect this kind of error in the meta-data unless another bundle wants to use classes from the exported package.

The BundleWiring seems to contain the information that I need:

val exportPackages = bundle.headers[EXPORT_PACKAGE]?.run(::extractPackageNames) ?: emptySet()

val wiring = bundle.adapt(BundleWiring::class.java)
for (exportPackage in exportPackages) {
     val paths = wiring.listResources(exportPackage.replace('.', '/'), null, 0) ?: emptyList()
     // assert that paths contains something other than just directories.
}

However, this check needs to run inside an OSGi framework and so is less than ideal.

It then occurred to me that Bnd might support this kind of validation already, and I duly discovered the aQute.bnd.osgi.Verifier class. This class looks like it performs a lot of other useful validation steps, and it wouldn't be difficult to wrap a Gradle task around it. However, it doesn't perform the specific check that I'm looking for, and I think that's

unlikely to be an oversight.

And so I have two questions please:

- Is the Export-Package validation that I seek so complicated that it needs to examine the BundleWiring? (E.g.searching bundles on the Bundle-ClassPath, which may have a Bundle-Classpath of their own, to the nth degree?)

- Is it worth using the Verifier anyway on a bundle which Bnd has just created? Or has Bnd already verified the bundle like this for me and so I'd just be duplicating the effort?

Thanks for any advice here,

Cheers,

Chris

[Fr Jeremy Krieg (Home)]

Hi Chris,

I pray you are well. 

Ray Augé has added OSGi verification tasks to the Junit5 and AssertJ projects. You could try using those as a template for reference.

Blessings, 

Fr Jeremy 

--
You received this message because you are subscribed to the Google Groups "bndtools-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bndtools-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bndtools-users/d307a93b-f390-4ba9-940e-53c28ba4e444n%40googlegroups.com.

[Raymond Auge]

I think Chris is looking to verify something different than what I did for JUnit5, which was to assure the produced bundles are a) valid & b) resolvable within the context of their dependencies.

However, Chris, I think what you really need to do is let bnd select exported packages by using bundle annotations like @Export and then what you'll find in the manifest should be generated, avoiding the need to question if it is correct or not. Learn to trust bnd. 🙂

- Ray

To view this discussion on the web visit https://groups.google.com/d/msgid/bndtools-users/CAO6F8YyanYbxGDHiE0-8scV2CWr_KxHDcj1jZfw9sE9yGA8dsg%40mail.gmail.com.

[Chris Rankin]

On Monday, 2 November 2020 at 01:06:24 UTC Fr Jeremy Krieg wrote:

Ray Augé has added OSGi verification tasks to the Junit5 and AssertJ projects. You could try using those as a template for reference.

Thanks, I was previously only aware of the TestOSGi task and so will investigate these. I am sure that they will be useful in any case.

Cheers,

Chris

[Chris Rankin]

On Monday, 2 November 2020 at 01:38:34 UTC Raymond Auge wrote:

However, Chris, I think what you really need to do is let bnd select exported packages by using bundle annotations like @Export and then what you'll find in the manifest should be generated, avoiding the need to question if it is correct or not. Learn to trust bnd. 🙂

Sigh, I wish that I could :-(. But unfortunately, I am trying to write a tool that will allow us to leverage OSGi for our particular use-case without exposing the gory details to anyone who doesn't need to know. I must also assume that at least some of our users will be bat-sh*t crazy!  So I really do need to analyse the resulting bundle from every different angle, and then complain loudly if anything is wrong. In particular, I must be able to detect "nonsense" package exports which may have been added manually in order to make other warnings "go away"...

No-one said this was going to be easy....

Thanks,

Chris

[BJ Hargrave]

It may be unusual, but it is permitted by the OSGi spec to export packages which do not exist in the bundle. This can be used as a "signal" to other bundles which can import the non-existent package. So we cannot make the Verifier fail when a bundle exports a package it does not contain. In pedantic mode, we may want to emit a warning message since the situation is unusual.

In your scenario, you may wish to author your own VerifierPlugin which your users configure into their builds. Your VerifierPlugin can do any additional constraint checking that makes sense for your product such as failing when a bundle exports a package which it does not contain.

--

You received this message because you are subscribed to the Google Groups "bndtools-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bndtools-user...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/bndtools-users/40f7c92a-981e-4bc9-ad71-d5d009dc907en%40googlegroups.com.

--

BJ

[Chris Rankin]

On Monday, 2 November 2020 at 14:46:04 UTC BJ Hargrave wrote:

It may be unusual, but it is permitted by the OSGi spec to export packages which do not exist in the bundle. This can be used as a "signal" to other bundles which can import the non-existent package. So we cannot make the Verifier fail when a bundle exports a package it does not contain. In pedantic mode, we may want to emit a warning message since the situation is unusual.

Thanks, I suspected that there was probably a reason... :-(.

 

In your scenario, you may wish to author your own VerifierPlugin which your users configure into their builds. Your VerifierPlugin can do any additional constraint checking that makes sense for your product such as failing when a bundle exports a package which it does not contain.

I am fine with writing my own verify logic, but does bndlib already contain any functionality that could help me walk a bundle's Bundle-Classpath please?

FWIW I applied the built-in Verifier to my bundles and discovered that none of my imported kotlin.* packages had any version information because I was still compiling against kotlin-stdlib and not kotlin-osgi-bundle! So that was worth knowing :-).

Cheers,

Chris

[BJ Hargrave]

I am not sure what help you need to walk the bundle classpath. The VerifierPlugin is called with an Analyzer object. You can call getBundleClasspath on that object to get the parsed Bundle-Classpath. See Analyzer.analyzeBundleClasspath to see how the Analyzer walks the bundle classpath.

--

You received this message because you are subscribed to the Google Groups "bndtools-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bndtools-user...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/bndtools-users/b0591774-c9b8-4680-b435-02396a275b6cn%40googlegroups.com.

--

BJ

[Chris Rankin]

BTW I see that the Verifier exempts javax.* packages from needing a version range when performing a "strict" check of the Import-Package header. Do you think that sun.* packages should also be exempt please? Because I cannot think of a version range that I could reasonably apply to sun.misc.

Cheers,

Chris

[BJ Hargrave]

I think for packages which come from the Java execution environment, the verifier should not care about package versions. You should open a github issue to discuss such a change.

--
You received this message because you are subscribed to the Google Groups "bndtools-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bndtools-user...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/bndtools-users/30f242cf-37b6-4e02-b101-dc974aa382efn%40googlegroups.com.

--

BJ

[Chris Rankin]

On Monday, 2 November 2020 at 19:36:29 UTC BJ Hargrave wrote:

I think for packages which come from the Java execution environment, the verifier should not care about package versions. You should open a github issue to discuss such a change.

Done: https://github.com/bndtools/bnd/issues/4388

I should probably also ask: Are there any plans to make a version range of '[0,0)' invalid,  please? I am currently using this impossible range to satisfy another Import-Header warning that I'd prefer to ignore completely  but cannot. (I added guava-29.0-jre to a Bundle-Classpath as part of a unit test, and discovered that Bnd disagreed with Guava about what its meta-data should look like! Gee, "Thanks for that, Guava!")

Cheers,

Chris

[BJ Hargrave]

Re: version ranges, I don't think there is any plan to make empty version ranges invalid. `[x,x)` is just an empty range as is `(x,x)` and `(x,x]`.

--

You received this message because you are subscribed to the Google Groups "bndtools-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bndtools-user...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/bndtools-users/5c752785-1862-4170-93a9-5df4f58ebe1dn%40googlegroups.com.

--

BJ

[Chris Rankin]

On Monday, 2 November 2020 at 21:53:14 UTC BJ Hargrave wrote:

Re: version ranges, I don't think there is any plan to make empty version ranges invalid. `[x,x)` is just an empty range as is `(x,x)` and `(x,x]`.

 

Heh, heh: funny you should say that... ;-D

Import Package com.google.apphosting.api has an empty version range syntax (0,0), likely want to use [0.0.0,0.0.0]

Import Package com.google.appengine.api has an empty version range syntax (0,0), likely want to use [0.0.0,0.0.0]

Import Package com.google.appengine.api.utils has an empty version range syntax (0,0), likely want to use [0.0.0,0.0.0]

It looks like Bnd 5.2.0 rejects (0,0) as invalid, although [0,0) is OK.

Cheers,

Chris