submodules released as über jars (eg from `sbt-assembly`) always have `MissingClassProblem`s and `None` compatibility

[rtyley]

I noticed that versionPolicyAssessCompatibility (added in PR https://github.com/scalacenter/sbt-version-policy/pull/184) always reports None compatibility for the aws-parameterstore-lambda submodule in the project play-secret-rotation (configured for sbt-version-policy with https://github.com/guardian/play-secret-rotation/pull/416), while all other modules are BinaryAndSourceCompatible (in fact even when there have been no code or dependency changes to the project at all since the last release).

This module is the only one in the play-secret-rotation project that's an sbt-assembly über jar with all of its dependencies (configured in its submodule build.sbt - because it's used in an AWS Lambda, where having a single jar makes for easier deployment).

sbt "show versionPolicyAssessCompatibility" [info] welcome to sbt 1.9.7 (Amazon.com Inc. Java 11.0.21) ... [info] set current project to play-secret-rotation-root (in build file:/Users/Roberto_Tyley/code/play-secret-rotation/) [info] aws-parameterstore-sdk-v1 / versionPolicyAssessCompatibility [info] Vector((com.gu.play-secret-rotation:aws-parameterstore-sdk-v1:6.0.0,BinaryAndSourceCompatible)) [info] aws-parameterstore-lambda / versionPolicyAssessCompatibility [info] Vector((com.gu.play-secret-rotation:aws-parameterstore-lambda:6.0.0,None)) [info] play-v28 / versionPolicyAssessCompatibility [info] Vector((com.gu.play-secret-rotation:play-v28:6.0.0,BinaryAndSourceCompatible)) [info] secret-generator / versionPolicyAssessCompatibility [info] Vector((com.gu.play-secret-rotation:secret-generator:6.0.0,BinaryAndSourceCompatible)) [info] core / versionPolicyAssessCompatibility [info] Vector((com.gu.play-secret-rotation:core:6.0.0,BinaryAndSourceCompatible)) ...

Running aws-parameterstore-lambda / versionPolicyCheck shows no 'dependency' issues, it's versionPolicyMimaCheck that fails, with hundreds of MissingClassProblems, one for each class from the dependencies that are later folded into the dependency by sbt-assembly:

...
[error]    * class software.amazon.ion.util.IonTextUtils#SymbolVariant does not have a correspondent in current version
[error]      filter with: ProblemFilters.exclude[MissingClassProblem]("software.amazon.ion.util.IonTextUtils$SymbolVariant")
[error]    * class software.amazon.ion.util.IonValueUtils does not have a correspondent in current version
[error]      filter with: ProblemFilters.exclude[MissingClassProblem]("software.amazon.ion.util.IonValueUtils")
[error]    * class software.amazon.ion.util.JarInfo does not have a correspondent in current version
[error]      filter with: ProblemFilters.exclude[MissingClassProblem]("software.amazon.ion.util.JarInfo")
[error]    * interface software.amazon.ion.util.PrivateFastAppendable does not have a correspondent in current version
[error]      filter with: ProblemFilters.exclude[MissingClassProblem]("software.amazon.ion.util.PrivateFastAppendable")
[error]    * class software.amazon.ion.util.Spans does not have a correspondent in current version
[error]      filter with: ProblemFilters.exclude[MissingClassProblem]("software.amazon.ion.util.Spans")
[error] versionPolicyMimaCheck failed
[error] (aws-parameterstore-lambda / versionPolicyMimaCheck) versionPolicyMimaCheck failed

Conceptually, I think it's possible that any über jar submodule is unlikely to ever suffer from the versioning issues that sbt-version-policy is designed to protect against - über jars are used as CLI tools, or AWS Lambdas - standalone programs. In the play-secret-rotation project I'm only publishing aws-parameterstore-lambda as a Maven artifact as it's a convenient place to publish to, for the purpose of distribution.

Workaround

I think a reasonable route is to set versionPolicyAssessCompatibility / skip := true in the submodule (as in https://github.com/guardian/play-secret-rotation/pull/420), but it did take a bit of digging to work out what the problem was and fix it - I'm creating this issue to partly record my findings, and to think about a better developer experience for developers using sbt-version-policy.

cc @julienrf

[julienrf]

Thank you @rtyley for the investigation and detailed report!

As you have noticed, what happens is that Mima compares the project classfiles (without the project's dependencies folded in) with the über-jar.

Conceptually, I think it's possible that any über jar submodule is unlikely to ever suffer from the versioning issues that sbt-version-policy is designed to protect against - über jars are used as CLI tools, or AWS Lambdas - standalone programs.

Yes, I agree with that. If play-secret-rotation is not “consumed” as a library, the versioning scheme implemented by sbt-version-policy is irrelevant, and it should be skipped.

That being said, it is probably possible to configure Mima to work correctly by customizing the setting mimaCurrentClassfiles in the project play-secret-rotation.

To be honest, I believe the solutions to handle this situation should be documented in Mima itself. I see that a discussion was opened, but it does not contain a conclusion: https://github.com/lightbend/mima/discussions/709.