The old way to customize CrossVersion results was a `String => String`
function called 'remapVersion', removed in
301ec787f2.
That was removed because it's not possible to serialise Function1s, and
we want to serialise CrossVersion (and therefore ModuleID, etc) to be
able to transfer them in sbt server.
This commit reintroduces a less-powerful way to vary the results of
apply CrossVersion, but just providing the opportunity to define a
suffix. From looking at the users of CrossVersion (Scala.js'
sbt-scalajs-plugin & Scala Native's sbt-crossproject) this looks to be
sufficient.
Fixes#1466 Ref #2786
Even after fixing the mediator issue, we still have spurious binary
version conflict warning that does not account for sandbox
configurations.
This change follows the scalaVersionConfigs work.
Fixes#2786. Ref #2634.
sbt 0.13.12 added Ivy mediator that enforces scalaOrganization and
scalaVersion for Scala toolchain artifacts.
This turns out to be a bit too aggressive because Ivy configurations
can be used as an independent dependency graph that does not rely on
the scalaVersion used by Compile configuration. By enforcing
scalaVersion in those graph causes runtime failure.
This change checks if the configuration extends Default, Compile,
Provided, or Optional before enforcing scalaVersion.
Fixes #2002/#1500
Given a dependency graph such as:
libraryDependencies += "com.google.guava" % "guava-tests" % "18.0"
libraryDependencies += "com.google.guava" % "guava-tests" % "18.0"
% "test" classifier "tests"
previous releases of sbt would drop the Test configuration from the
classifier "tests" artifacts, and end up including the test JARs into
the Compile configuration instead of the Test configuration, which
would result in runtime error.
This fix configures the explicit artifacts into the configuration
during merge even when it says `"*"`.
Move the toString implementation from ConfigurationReportExtra to inside
the ConfigurationReport JSON schema definition, that way the synthetic
toString generated by contraband doesn't override the carefully defined
one.
Two instance of functions defined in the same way don't equal themselves, but
the same instance of a function does. So by using a val idStringFun for full and
binary, and making Binary and Full case classes there are much better chances
that ModuleId's defined in the same way will be equal.
Consider a configuration where we have two projects, A and B.
A has a library dependency on "a" % "b" % "1.0.0" % "compile->runtime"
and "a" % "b" % "1.0.0" % "compile->runtime2"
B depends on project A, and has a library dependency on
"a" % "b" % "1.0.1" % "compile->runtime".
Note that project B depends on a more recent version of "a" % "b" than
project A, and that it depends ONLY on it's "runtime" configuration.
However, when compiling project B, we expect to have on the classpath
project A, and "a" % "b" % "1.0.1" % "compile->runtime" AND
"a" % "b" % "1.0.1" % "compile->runtime2" because it is part of the
compile configuration of project A.
This commit changes the cached resolution engine so that it behaves like
that, by first resolving dependencies on other project and then ensuring
that the dependent project specifies dependencies on the same
configurations.
Mark test dependency-management/cached-resolution-configurations as
passing.