Beim Upgraden unserer Build von 12.4 auf 13.1 habe ich festgestellt, dass obwohl das Build scalaVersion := "2.10.2" angegeben hat, das resultierende Archiv (erstellt über das sbt-pack Plugin) scala-library-2.10.3.jar enthielt. Ein kurzer Check bestätigte, dass der Build von 12.4 scala-library-2.10.2.jar enthielt.
Es scheint, dass sbt 0.13 eine Änderung zur Behandlung der Scala-Bibliotheken als normale Abhängigkeiten enthielt, mit der Konsequenz, dass, wenn eine Projektabhängigkeit mit einer späteren 2.10.x-Version von scala erstellt wurde, diese transitive Abhängigkeit die Efeu-Abhängigkeit "gewinnen" würde Auflösungskonfliktauflösung, und die Klassenpfade compile, test und run enthalten die neuere Version von scala-Bibliotheken.
Ist dies das gewünschte Verhalten oder ein Fehler in sbt 0.13?
Wenn das gewünschte Verhalten, dann bedeutet das, dass ich die Mechanismen verwenden muss, um die Konfliktlösung zu erzwingen / zu überschreiben, um meine gewünschte Version der Scala-Bibliotheken zu verwenden? (Wenn dies der Fall ist, scheint die Konfiguration der scalaVersion-Konfiguration etwas sinnlos zu sein ....)
Hier ist ein extrem minimaler Testfall, um das Verhalten zu veranschaulichen:
%Vor%build.sbt:
%Vor%build.properties:
%Vor%Akka 2.2.4 wurde gegen scala 2.10.2 gebaut, also sbt starten und "update" ausführen, "show update", "show compile: dependencyClasspath", "show test: dependencyClasspath" und "show runtime: dependencyClasspath" Alle zeigen scala-library 2.10.2 auf dem Klassenpfad.
Der Wechsel zu Akka 2.3.0, das gegen scala 2.10.3 erstellt wurde, führt dazu, dass die scala-Bibliothek 2.10.3 auf allen Klassenpfaden erscheint, und "show update" zeigt eindeutig, dass 2.10.2 durch die Konfliktlösung von Ivy geräumt wird.
Interessanterweise (und inkonsistent) führt die Eingabe der REPL in beiden Fällen (über den Befehl sbt console) zur Verwendung von scala 2.10.2.
Laut den Dokumenten , in sbt 0.13
Die scalaVersion konfiguriert die Version von Scala, die für die Kompilierung verwendet wird. Standardmäßig fügt sbt mit dieser Version auch eine Abhängigkeit von der Scala-Bibliothek hinzu.
Davon ausgehend würde ich erwarten, dass der Klassenpfad für die Kompilierung in beiden Fällen 2.10.2 enthält.
die Versionshinweise für 0.13 sagen
Scala-Abhängigkeiten (wie scala-library und scala-compiler) werden nun über die normale Update-Aufgabe aufgelöst
was zumindest das beobachtete Verhalten erklärt.
Sie haben geschrieben:
Es scheint, dass sbt 0.13 eine Änderung zur Behandlung der Scala-Bibliotheken als normale Abhängigkeiten enthielt, mit der Konsequenz, dass, wenn eine Projektabhängigkeit mit einer späteren 2.10.x-Version von scala erstellt wurde, diese transitive Abhängigkeit die Efeu-Abhängigkeit "gewinnen" würde Auflösungskonfliktauflösung, und die Klassenpfade compile, test und run enthalten die neuere Version von scala-Bibliotheken.
sbt 0.13.0 Änderungen haben etwas widersprüchliche Anmerkung zu diesem Thema. Funktionen, Korrekturen, Änderungen mit Auswirkungen auf die Kompatibilität Abschnitt sagt:
- sbt hebt die Scala-Version in Abhängigkeiten nicht mehr auf. Dadurch können unabhängige Konfigurationen von verschiedenen Scala-Versionen abhängig sein und Scala-Abhängigkeiten anders als scala-library als normale Abhängigkeiten behandelt werden. Es kann jedoch zu anderen aufgelösten Versionen als scalaVersion für diese anderen Scala-Bibliotheken kommen.
Auflösen von Scala-Abhängigkeiten heißt es :
Scala-Abhängigkeiten ( wie scala-library und scala-compiler) werden jetzt über die normale
update-Aufgabe aufgelöst.
(Hervorhebung von Eugene) Also die schnelle Antwort auf Ihre "Ist das das gewünschte Verhalten oder ein Fehler in sbt 0.13?" wie Sie bereits selbst beantwortet haben, ist: In sbt 0.13.x scheint dieses Verhalten beabsichtigt zu sein. Akka 2.3.0 hängt von der Scala-Bibliothek 2.10.3 ab und Ivy hat die Scala-Bibliothek 2.10.2 zugunsten von 2.10.3 geräumt.
Um dies zu umgehen, können Sie die Einstellung dependencyOverrides wie folgt verwenden:
Vorher:
%Vor%Nachher:
%Vor% Ihre Frage war nicht, ob das per Design ist, aber ob das wünschenswert ist. Ich denke, dass das aktuelle Verhalten ziemlich überraschend ist, und sbt sollte zumindest verbessern, um die Build-Benutzer von diesem Verhalten zu benachrichtigen. Und vielleicht ändern Sie die Standard-Ivy-Konfliktmanagement-Richtlinie auf force() der in scalaVersion angegebenen Version. Hier sind zwei GitHub-Probleme, die ich erstellt habe: