Gleiche Gradle-Dateien, gleiche Code-Basis, verschiedene Abhängigkeitsgraphen für verschiedene Entwickler

Question

Dieses Problem scheint mir ein echtes Rätsel zu sein. Wir arbeiten an einer Spring REST App. In meinem Team haben wir Jenkins einen Build auf allen Checkins (CI Build). Außerdem gibt es einen offiziellen Build, der sonst jeden Abend gemacht wird. Einige Integrationstests haben vor kurzem während des CI-Builds einen Fehler verursacht, und wir haben die Ursache auf Jar-Konflikte zurückgeführt. Wir haben jedoch die transitiven Abhängigkeiten, die diese Konflikte früher verursacht haben, erfolgreich ausgeschlossen, und für den offiziellen Build und für einige Entwickler im Team gilt das immer noch. Für andere ist es nicht mehr.

Wir haben die gleiche Code-Basis und die gleichen Gradle-Dateien. Wenn ich die Abhängigkeitsaufgabe auf meinem System ausführe, habe ich einen langen Baum von transitiven Abhängigkeiten in einem Teilprojekt (wie die Jenkins-Maschine), während andere keinen solchen Baum haben. Außerdem ist die Größe des WAR für einige Entwickler um einige Größenordnungen größer als für andere. Die transitiven Abhängigkeiten stammen von einem anderen verwandten Projekt, das auf Nexus hochgeladen wurde.

Ich habe Abhängigkeiten sowohl auf meiner Maschine und der Jenkins-Maschine aktualisiert, und sogar gelöscht .gradle, aber ohne Erfolg.

Es klingt wie etwas Umwelt, aber die Gradle-Versionen und Java-Versionen sind alle in etwa gleich, höchstens ein paar Nebenversionen.

Irgendwelche Ideen darüber, was diese Diskrepanz verursachen könnte?

Answer 1

Sie könnten Ihre Abhängigkeiten auf bestimmte Versionen auf der ganzen Linie zwingen

def gsonModule = 'com.google.code.gson:gson' 
configurations.all { 
    resolutionStrategy { 
     // add dependency substitution rules 
     dependencySubstitution { 
      substitute module(gsonModule) with module("$gsonModule:2.6.1") 
     } 
    } 
} 

// note: configurations block must be above the dependencies 
// or build will error 
dependencies { 
    compile "$gsonModule:2.7" 
} 

Dann, wenn jeder Entwickler/CI/test/CD die Build Ihre resolutionStrategy Kräfte Konsistenz über alle Compilations läuft. Standardverhalten in Gradle ist bei Versionskonflikten die neuere Version wird verwendet. Dies wird alle Versionen unabhängig von ihrer deklarierten Version zwingen.

$ ./gradlew dependencies --configuration compile -q 

------------------------------------------------------------ 
Root project 
------------------------------------------------------------ 

compile - Dependencies for source set 'main'. 
\--- com.google.code.gson:gson:2.7 -> 2.6.1 

Referenz: https://docs.gradle.org/current/dsl/org.gradle.api.artifacts.ResolutionStrategy.html

Answer 2

Sie gradle Wrapper verwenden sollten die gleiche gradle Version im gesamten Gebäude, um zu gewährleisten, eine gewisse Möglichkeit, dass ein Faktor auszuschließen.

Fügen Sie auch --refresh-dependencies zur gradle-Befehlszeile hinzu. Es kann sein, dass einige Ihrer Abhängigkeiten nicht korrekt versioniert werden, und dieses Flag überprüft jedes Mal, wenn nur die letzten gezogen werden.

Betrachten Sie schließlich die Workstations, die unterschiedliche Ergebnisse haben, und stellen Sie sicher, dass Sie in Ihrem Benutzerordner für Hauptbenutzer und im Projektordner identische gradle.properties haben.

Answer 3

Zunächst vielen Dank für die schnellen Antworten, aber ich habe ein Update:

Kurz gesagt, einer meiner Kollegen eines der Probleme identifiziert. Ich kann nicht ins Detail gehen, aber die Gradle-Dateien haben praktische Funktionen, um entweder ein anderes Projekt von Nexus herunterzuladen (zum Beispiel das verwandte Projekt, das ich oben erwähnt habe) oder ein lokal erstelltes Artefakt zu verwenden, falls es existiert.

Letzteres löst das Problem. Das Herunterladen von Nexus (wie es Jenkins getan hat und was Sie tun sollten) ermöglicht das Auftreten des Problems und setzt es frei. Ich glaube nicht, dass dies die Build-Reihenfolge beeinflusst, aber es wirkt sich auf die transitiven Abhängigkeiten aus, die gezogen werden.

Es gibt auch einige Probleme in den Abhängigkeiten der verschiedenen Teilprojekte: z., ein Projekt, das keine Abhängigkeiten haben soll, hat einen, und dieser ist ein großer Schuldiger, wenn es um transitive Abhängigkeiten geht. Wenn also dieses Basisprojekt von anderen Projekten eingezogen wird, hat es Welleneffekte. Und einige dieser Abhängigkeitsblöcke müssen bereinigt werden.

Nochmals vielen Dank für die Antworten!