You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
$ cat build.sbt
lazyvalTheDude= config("dude")
lazyvalrootProj= (project in file(".")).
configs(TheDude).
settings(inConfig(TheDude)(Defaults.compileSettings): _*).
settings(
name :="hello",
version :="0.1.0-SNAPSHOT",
scalaVersion :="2.11.1",
libraryDependencies +="org.scala-lang"%"scala-library"%"2.10.4"%TheDude
)
$ sbt
hello> clean
hello> dude:compile
problem
hello> dude:compile
[info] Updating {file:/Users/eugene/work/quick-test/minimal-scala/}rootProj...
[warn] Binary version (2.10) for dependency org.scala-lang#scala-library;2.10.4
[warn] in hello#hello_2.11;0.1.0-SNAPSHOT differs from Scala binary version in project (2.11).
[info] Resolving jline#jline;2.11 ...
[info] Done updating.
TheDude configuration is independent from Compile, so the fact the warning is incorrect there.
expectation
Should we allow scalaVersion to be set on custom configurations? If so does that change the behavior of %%? Probably not because you could have more than one config like default->@;runtime,test->runtime. So that means, each configuration should use scala-library's version to be the basis on checking for binary version conflicts.
The text was updated successfully, but these errors were encountered:
Fixessbt#1466 Ref sbt#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.
Fixessbt#1466 Ref sbt#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.
Fixessbt#1466 Ref sbt#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.
steps
problem
TheDude
configuration is independent fromCompile
, so the fact the warning is incorrect there.expectation
Should we allow
scalaVersion
to be set on custom configurations? If so does that change the behavior of%%
? Probably not because you could have more than one config likedefault->@;runtime,test->runtime
. So that means, each configuration should usescala-library
's version to be the basis on checking for binary version conflicts.The text was updated successfully, but these errors were encountered: