caffeine-3.1.1.jar pushed to MavenCentral announces itself as SNAPSHOT

[veita]

The JAR announces itself as a SNAPSHOT version instead of a release version. This causes trouble in automated dependency checks.

Manifest-Version: 1.0
Automatic-Module-Name: com.github.benmanes.caffeine
Bnd-LastModified: 1653540837798
Bundle-License: https://www.apache.org/licenses/LICENSE-2.0
Bundle-ManifestVersion: 2
Bundle-Name: com.github.ben-manes.caffeine
Bundle-SymbolicName: com.github.ben-manes.caffeine
Bundle-Version: 3.1.1.SNAPSHOT
Created-By: 11.0.15 (Azul Systems, Inc.)
Export-Package: com.github.benmanes.caffeine.cache;uses:="com.github.b
 enmanes.caffeine.cache.stats";version="3.1.1",com.github.benmanes.caf
 feine.cache.stats;uses:="com.github.benmanes.caffeine.cache";version=
 "3.1.1",com.github.benmanes.caffeine;version="3.1.1"
Require-Capability: osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=11))"
Tool: Bnd-6.2.0.202202251641

[ben-manes]

Oh, good catch. That is for OSGi and is generated by the bnd plugin. What do you think would cause this? It looks as though 3.1.0 did not have this problem, but the version wasn't updated in between so I am unsure what the root cause actually is.

[ben-manes]

From the diff, this is the first release that has Gradle Enterprise enabled. When I disable that locally and create a release jar, then the Bundle-Version is correct. This implies a task caching mistake. A simple fix would be to disable caching for the release workflow to ensure that it is pristine.

@clayburn do you have any suggestions here?

[clayburn]

Short answer: I think you can get the behavior you are looking for by adding the version as an input to the jar task.

Longer answer: I think this is the result of an action that the bnd plugin is adding to the Jar task here. It looks like that action is effectively adding inputs to the task but not actually declaring them as inputs. So the above is a workaround for you for now, but I want to file a ticket over on bnd to address this.

[ben-manes]

Thanks @clayburn! I took your advice and the custom task input appears to solve it elegantly.

@veita My OSGi tests (via pax-exam) seems to work fine with this goof, so I am inclined to wait until the next release (no target date yet). If this is causing OSGi issues that my tests don't catch, please let me know and we can decide on if a release makes sense. Since most dependency checking tools look at other metadata, like version updates and license compliance, it seems like this has low impact. I might simply be ignorant though, so do feel welcome to advocate.

[clayburn]

@ben-manes: From bndtools/bnd#5279: bnd has a fix for this issue that should show up in 6.4.