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