sbt-buildinfo 0.9.0 is published for sbt 1.
BuildInfoKey conversion potentially breaking semantic change
TL;DR No need for
BuildInfoKey.ofN(...) any more. Use
BuildInfoKey.outOfGraphUnsafe if your build definition is now circular.
sbt-buildinfo 0.8.0 deprecated the original
BuildInfoKey.Entry[A] implicit and explicit
BuildInfoKey.apply respectively), that executed the underlying sbt Task
out of sbt’s task graph execution, in favour of a newly introduced
BuildInfoKey.ofN(...) API, which correctly wired up the task graph. See #114.
As it was implemented (and released) it interacted poorly with sbt-buildinfo’s
(#117), due to a mistake in the implementation and test coverage.
In resolving the issue it became clear that instead of introducing a new API, that required sbt-buildinfo users
to change their source code to use, the already used conversions could have been modified to use the new
However, this change breaks any build definition that declares as a build info key any
TaskKey that depends on
resourceGenerators, because the build definiton would now be circular and fail to load.
To fix this breaking semantic change the user has to either drop the key used, choose another key, or fallback
to the previous semantics by using the not-deprecated
BuildInfoKey.outOfGraphUnsafe API, also introduced in
Add direct support for sbt’s
A number of keys defined by sbt use sbt’s
Attributed type, specifically the keys that define classpaths.
Prior to this change defining any of these keys as a build info key would generate
would be simply converted to string with
toString. sbt-buildinfo 0.9.0 introduces direct support for these
keys so they generate
toJson more JSONish
sbt-buildinfo is able to generate
toJson method using the following setting:
buildInfoOptions += BuildInfoOption.ToJson
sbt-buildinfo 0.9.0 makes the JSON encoding more natural:
"libraryDependencies" : [ "org.scala-lang:scala-library:2.12.4", "com.lihaoyi:acyclic:0.1.7:plugin->default(compile)", .....]
Do not generate multi-parameter infix calls
Multi-parameter infix calls may be removed in the future, so it’s better
not to generate this kind of code.