OSGi version range for Guava is too strict

[guw]

In Eclipse we are moving away from having too strict version on package imports for Guava. It caused a quite a few issues over the years. It would be great if the OSGi metadata can be relaxed to only have a lower bound on the Guava package imports.

See eclipse-equinox/equinox#304 (comment) for more details.

[ben-manes]

I'm not really sure what to do here because this is automatically done by the bnd plugin.

There is common configuration like descriptions,

caffeine/gradle/plugins/src/main/kotlin/lifecycle/java-library-caffeine-conventions.gradle.kts

Lines 64 to 77 in 586fe8c

	bundle {
	properties = projectDescription.map {
	mapOf("project.description" to it)
	}
	bnd(mapOf(
	"Bundle-License" to "https://www.apache.org/licenses/LICENSE-2.0",
	"Build-Jdk-Spec" to java.toolchain.languageVersion.get(),
	"Implementation-Title" to project.description,
	"Bundle-Description" to project.description,
	"Implementation-Version" to version,
	"-noextraheaders" to true,
	"-reproducible" to true,
	"-snapshot" to "SNAPSHOT"))
	}

and project-specific like package exports,

caffeine/guava/build.gradle.kts

Lines 37 to 47 in 586fe8c

	tasks.jar {
	bundle.bnd(mapOf(
	"Bundle-SymbolicName" to "com.github.ben-manes.caffeine.guava",
	"Import-Package" to listOf(
	"com.google.common.cache",
	"com.google.common.util.concurrent",
	"com.github.benmanes.caffeine.cache",
	"com.github.benmanes.caffeine.cache.stats").joinToString(","),
	"Export-Package" to "com.github.benmanes.caffeine.guava",
	"Automatic-Module-Name" to "com.github.benmanes.caffeine.guava"))
	}

The plugin is the one setting the version based on the dependencies, e.g.

Export-Package: com.github.benmanes.caffeine.guava;uses:="com.github.b
 enmanes.caffeine.cache,com.google.common.cache";version="3.1.9"
Import-Package: com.google.common.cache;version="[32.1,33)",com.google
 .common.util.concurrent;version="[32.1,33)",com.github.benmanes.caffe
 ine.cache;version="[3.1,4)",com.github.benmanes.caffeine.cache.stats;
 version="[3.1,4)"

The closest I see their instruction -nodefaultversion to "not add a default version to exported packages when no version is present." I don't know if that's desired or if it would cause more pains?

This package could use a very old version of Guava, but I also think keeping the dependency up to date is worthwhile. I guess if we add the version tag ourselves then it won't be computed and we could use an old version as a minimum, like ;version=20.0. wdyt?

I am not very familiar with osgi and rely on bnd + pax-exam tests to be compliant. Therefore any changes here relies on experts as I'll be ignorant to whether a suggested change is good or bad, which makes me hesitant to muck around too much.

[HannesWell]

I guess if we add the version tag ourselves then it won't be computed and we could use an old version as a minimum, like ;version=20.0. wdyt?

Yes that should work. Furthermore you don't have to list all packages you need explicitly. You could do something like:
com.google.common.*;version="20.0"
and the bnd-lib will compute the actually used bundles for you automatically.
To be sure I suggest you inspect the generated manifest from a local/CI build (at least that's what I'm usually doing in such cases).

[guw]

@ben-manes Any chance you can push a new release with the updated jars? We are being hit by the issue again (salesforce/bazel-vscode-java#109)