Version attribute of DynamicImport-Package with -includeresource for Import-Package

GENERAL
1

Question:

Should the version attribute of DynamicImport-Package in a dependency included via -includeresource be considered by bnd for calculating the Import-Package header?

Scenario:

My Wrapper Bundle A:

-includeresource: \
	${repo;io.micrometer:micrometer-core;latest}; lib:=true,\


Import-Package: *

Bnd finds, that this dependecy references com.github.benmanes.caffeine.cache in its .class files. And also the dependency specifies a DynamicImport-Package for that package with a version.

io.micrometer:micrometer-core:

DynamicImport-Package: com.github.benmanes.caffeine.cache;version="2.9.3"

which includes a versionrange >=2.9.3

But my build Wrapper Bundle A .jar’s MANIFEST.MF contains :

Import-Package: com.github.benmanes.caffeine.cache

WITHOUT a version.

The reason I ask is that I currently get a pendantic warning

Imports that lack version ranges: [com.github.benmanes.caffeine.cache]

So my question is:
Is it correct that the Import-Package does not have a version?
Or could / should bnd theoretically use the information of DynamicImport-Package somehow?

Or if not adding the version is ok, could I maybe try to suppress the pedantic warning, if that bundle is part of a DynamicImport-Package? (i read here that for DynamicImport-Package the version is not that important)

E.g. there is Analyzer.getManifestInfoFromClasspath(Jar jar, Packages classpathExports, Contracts contracts) where I would have access to the domain.getDynamicImportPackage()

If this is something bnd could / should handle I could start looking into a PR, but wanted to ask first.

Thoughts? @pkriens @bjhargrave

2

DynamicImport-Package is a hack since the package provider is undefined. It is a fall back to the time of long classpaths. It is a last bet best effort. We likely never look in this header to get metadata. I always disliked it.

I don’t think it is worth the effort to learn the version from DynamicImport-Package since it is not well defined anyway. But for this purpose it might be useful so I won’t object.

3

Yeah remembered various comments about it :slight_smile:

Do you mean the purpose of supressing this warning?

What would be normal way to avoid that warning Imports that lack version ranges: [com.github.benmanes.caffeine.cache] if it was caused by an -includeresource / jar wrapping?

4

On that note:

Just found a very useful post in the old forum by @rotty3000 :

As requested here I will try to also add that to the manual somewhere. Suggestions welcome.

1 Like
5

The embedded JAR’s DynamicImport-Package header won’t set a version on the wrapper’s Import-Package. Once its classes are included in Bundle A, the nested manifest isn’t an active bundle manifest; bnd derives the wrapper’s imports from the class references and available package metadata. Add an explicit version range to Bundle A’s import if you know the compatible Caffeine versions. Suppressing the pedantic warning is also reasonable if the unversioned import is intentional, but the nested dynamic-import constraint doesn’t provide a basis for choosing that range.