at com.acme.utils.SomeSpec.$spock_initializeFields(SomeSpec.groovy)
Caused by:groovy.lang.GroovyRuntimeException:Conflicting module versions.Module[groovy-all isloaded inversion2.4.9andyou are trying toload version2.4.10
at groovy.lang.GroovySystem.<clinit>(GroovySystem.java:36)
...1more
, bei Ausführen des Tests aus IntelliJ heraus; per Kommandozeile geht’s.
Internet sagt, man müsse die Dependency excluden (lokal oder global), um Sie dann in nur der gewünschten Version wieder zu includen, aber das führte bei mir bestenfalls nicht zum Erfolg, und schlimmstenfalls zu
Error:Cannot compile Groovy files: no Groovy library is defined for module ‘my-module_test’
Internet sagt weiterhin, man könne eine bestimme Version forcieren, aber das hat bei mir genau gar keine Auswirkungen.
Geholfen hat dann, das Setup aus compile und testCompile zu überprüfen: Ich hatte ein Modul mit Test-Sourcen als compile project, die Dependency org.codehaus.groovy:groovy-all:2.4.10 aber als test-compile eingebunden. Korrekt ist in dem Fall, das Modul als testCompile project einzubinden (oder alternativ die Dependency als compile, aber hier wäre das “falsch rum”).
Offenbar gilt von der Shell aus die höhere (oder die später deklarierte?) (transitive) Dependency, in IntelliJ aber die zuerst deklarierte.
Neulich™ hatte ich das Problem, dass ein UTF-8-enthaltender String falsch nach XML transformiert wurde. UTF-8 ist (? war es zumindest früher oft) so eine Sache in Java, man muss(te) an drölf Stellen das Encoding explizit setzen; dazu gehörten zB Stream, Writer/Reader, StringBuilder, etc pp. Das mag inzwischen anders sein, denn nach langem Debugging stellte sich raus, dass nur das File-Encoding in IntelliJ falsch gesetzt war – der Code funkionierte ohne Änderung, die Quelle des Strings war bereits fehlerhaft gespeichert. Irreführenderweise hatte der IntelliJ-Debugger den String die ganze Kette hindurch korrekt angezeigt. “Nimm IntelliJ” haben sie gesagt, “das funktioniert super” haben sie gesagt. m(
Wie dem auch sei: Da UTF-8 an der Stelle zwingend gefordert war, musste sichergestellt werden, dass kein Entwickler, aus welchen Gründen auch immer, ein anderes Encoding einschleust, bzw., wie in diesem Fall, UTF-8 durch falsch konfiguriertes Encoding kaputtspeichert. Ein Ansatz könnte sein, im Git-Repo UTF-8 zu erzwingen. Ein Ansatz dafür kann sein, das Encoding in einem Git-Hook zu prüfen. Anbieten tun sich pre-commit (der erste Hook, der greift; client-seitig; Beispiel [1] [2]) und pre-receive (der erste serverseitige Hook; Beispiel).
[Für Stash/Bitbucket Server scheint es auch Möglichkeiten zu geben; ein fertiges Plugin habe ich aber nicht gefunden.]
pre-commit hat den Vorteil, dass sich keine Commits aufstauen, bevor das Problem auffällt. Dafür müssen lokale Hooks aufwändig verteilt/aktiviert werden – bsplw. über separat eingecheckte Verzeichnisse, die gesymlinkt (aber was ist mit Windows? Was mit wirklichlokalen Hooks? Und was ist noch zu beachten?) oder kopiert werden. Für pre-receive gelten Vor- und Nachteile inversiert, außerdem benötigt man Zugriff auf den Server auf Dateisystemebene.
Lange Rede, kurzer Sinn: Aus Gründen haben wir uns für einen pre-commit entschieden. Das Skript muss dabei .git/hooks/pre-commit heißen. Ich hätte ein Verzeichnis pre-commit mit Skripten darin erwartet, aber das wirft einen
cannot spawn .git/hooks/pre-commit: No such file or directory
Und es war gar nicht so einfach, eine Datei überhaupt mit dem falschen Encoding abzuspeichern. Sublime und Notepad++ haben sich (stillschweigend, was Notepad++ angeht) geweigert. Schließlich habe ich es mit IntelliJ geschafft, was allerdings auch gewarnt hat. Keine Ahnung, wie das ursprüngliche Problem überhaupt zustande kam.
[Achtung: Das Skript kann nicht mit Binaries umgehen! Und das schließt bereits .woff ein. Offenbar ist es auch nicht trivial, Binaries zu erkennen; Internet nutzt dazu die Dateigröße oder auch Fileextensions. Ersteres scheint mir unzuverlässig, man denke an kleine Grafiken. Zweiteres ist sehr aufwändig…]
Beispielhafte Ausgabe (“ISO 8859-1.txt” heißt die Datei):
Und, der Vollständigkeit halber: Die Einstellung von Intellij:
btw: In Eclipse kann man Settings als Textfile exportieren und bsplw. in einem Repo ablegen – in IntelliJ scheint das nur als .jar exportierbar zu sein, bzw. über einen “IntelliJ Configuration Server” (WTF!?) verteilbar?