[reiabreu]

The 3.2.0 candidate has two binary tarballs built from the same tag, and jspecify-1.0.1.jar sits in lib/ in one and in lib-common/ in the other. This makes both give the same layout.

Upgrade notes

storm-client no longer brings org.jspecify:jspecify as a transitive compile dependency (it came through the dependency-reduced pom of storm-shaded-deps). If your topology code uses org.jspecify annotations, declare the dependency yourself, for example org.jspecify:jspecify:1.0.1.

In the binary distribution, jspecify is in lib/ (daemon classpath) in every build, so it is no longer on the worker classpath. It is an annotations-only library and is not needed at runtime.

Details

Cause

• storm-shaded-deps bundles its libraries with the shade plugin, and the libraries are declared <optional>true</optional>. The plugin's dependency-reduced pom promotes their transitive dependencies and keeps the optional flag.
• jspecify is the only promoted dependency it left non-optional. error_prone_annotations, j2objc-annotations and failureaccess are optional or daemon-only in both builds.
• A module that resolves storm-shaded-deps from the Maven repository reads that reduced pom, so jspecify lands on the worker classpath, and dedup-libs.py moves it to lib-common. In a reactor build, as release:perform does, Maven takes the model of storm-shaded-deps from the reactor (ReactorReader.findModel returns MavenProject.getModel(), checked in the bytecode of Maven 3.9.16), so the reduced pom written by the shade step is never read. That model declares Guava as optional and does not declare jspecify, so the worker classpath does not get it and it stays in lib.

Change

• Declare org.jspecify:jspecify as <optional>true</optional> in storm-shaded-deps/pom.xml, like the libraries around it. The version is already managed in the root pom. jspecify then stays in lib/ in every build mode, as the other Guava annotation jars do.

Verified on a scratch checkout of the v3.2.0 tag with this change, using an isolated local repository so the real one was not touched:

• The reduced pom of storm-shaded-deps now lists jspecify with optional=true.

• storm-client-bin built in a reactor and built on its own: lib-worker has 39 jars in both, no jspecify, with identical names and SHA-256 hashes. Before the change the standalone build had 40.

• final-package daemon jars (copy-dependencies, runtime): 88 jars in both modes, unchanged from before, jspecify included.

• Workers without jspecify: the full 3.2.0 distribution with jspecify moved from lib-common/ to lib/ (the layout this change produces) passed the smoke test (WordCount, Lambda, MultiThreadWordCount and the Kafka example, 0 failed tuples), and no worker log had a NoClassDefFoundError or ClassNotFoundException. jspecify has only 4 annotation types, and storm-client does not reference them.

Not verified

• I did not rebuild the full tarballs in both modes and compare them. Build timestamps in the UI files and the branch= line in the version-info files will still differ between any two builds.
• I did not run this through the smoke tests.

🤖 Generated with Claude Code