Problem
Compile / smithy4sWildcardArgument is a per-project build setting derived from scalaVersion and scalacOptions.
The sbt plugin hands it to codegen by writing a synthetic file generated-metadata.smithy.
Smithy rejects conflicting values of this metadata.
The result: two libraries that differ only in their own scalac options become incompatible for any downstream smithy4s consumer.
Reproduction
project/build.properties
project/plugins.sbt
addSbtPlugin("com.disneystreaming.smithy4s" % "smithy4s-sbt-codegen" % "0.19.11")
build.sbt
ThisBuild / scalaVersion := "2.13.16"
// derives smithy4sWildcardArgument = "_"
lazy val libA = project
.enablePlugins(Smithy4sCodegenPlugin)
// same plugin, same Scala version; derives "?"
lazy val libB = project
.enablePlugins(Smithy4sCodegenPlugin)
.settings(
addCompilerPlugin("org.typelevel" %% "kind-projector" % "0.13.4" cross CrossVersion.full),
scalacOptions += "-P:kind-projector:underscore-placeholders",
)
lazy val app = project
.enablePlugins(Smithy4sCodegenPlugin)
.dependsOn(libA, libB)
then sbt compile fails with:
[error] (app / Compile / smithy4sCodegen) software.amazon.smithy.model.validation.ValidatedResultException:
Result contained ERROR severity validation events:
[ERROR] -: Metadata conflict for key `smithy4sWildcardArgument`. Defined in both
`jar:file:///.../libB/target/scala-2.13/libb_2.13-0.1.0.jar!/META-INF/smithy/generated-metadata.smithy [2, 37]`
and
`jar:file:///.../libA/target/scala-2.13/liba_2.13-0.1.0.jar!/META-INF/smithy/generated-metadata.smithy [2, 37]`
which is unexpected, because without Smithy, such a module and options structure would compile and be ok.
I couldn't find an easy fix for that, and I see generated-metadata.smithy being mentioned in tests. Is there any important reason for such behavior?
Problem
Compile / smithy4sWildcardArgumentis a per-project build setting derived fromscalaVersionandscalacOptions.The sbt plugin hands it to codegen by writing a synthetic file
generated-metadata.smithy.Smithy rejects conflicting values of this metadata.
The result: two libraries that differ only in their own scalac options become incompatible for any downstream smithy4s consumer.
Reproduction
project/build.propertiesproject/plugins.sbtbuild.sbtthen
sbt compilefails with:which is unexpected, because without Smithy, such a module and options structure would compile and be ok.
I couldn't find an easy fix for that, and I see
generated-metadata.smithybeing mentioned in tests. Is there any important reason for such behavior?