Ich versuche, einen Weg zu schaffen, auf dem hermetische Builds erreicht werden können, während ich immer noch auf SNAPSHOT-Abhängigkeiten in Ihrem Projekt angewiesen bin.
Sagen wir zum Beispiel, dass ich ein Projekt habe, das eine Abhängigkeitsstruktur wie folgt hat:
%Vor%Was ich jetzt tun möchte, ist, alle SNAPSHOT-Abhängigkeiten lokal in etwas aufzulösen, das mit meiner aktuellen Version zusammenhängt, und diese dann als Releases in das Nexus-Versions-Repository zu deployen. Nicht alle diese Abhängigkeiten sind intern, so dass ich nicht einfach nur eine Veröffentlichung auf jedem machen kann.
In diesem Beispiel würde also other-1.2-SNAPSHOT so etwas wie other-1.2-mine-1.2.3 und thing-3.1-SNAPSHOT würde thing-3.1-mine-1.2.3 werden. Dies ist relativ trivial in etwa 60 Zeilen Python.
Das Problem besteht jedoch darin, transitive SNAPSHOTs in konkrete Versionen aufzulösen. Also muss ich auch gizmo-6.1.3-SNAPSHOT in gizmo-6.1.3-mine.1.2.3 umwandeln und thing-3.1-mine-1.2.3 davon abhängig machen.
Dies ist nur ein Beispiel dafür, wie ich erreichen kann, was ich will. Das Ziel ist, dass ich in ein oder zwei Jahren den Release-Zweig für Version 1.2.3 auschecken und mvn clean package oder ähnliches ausführen kann, ohne mich um die Auflösung längst vergangener SNAPSHOT-Abhängigkeiten kümmern zu müssen.
Es ist wichtig, dass dieser Zweig kompilierbar ist und nicht nur alle Abhängigkeiten mit etwas wie der jar-and-dependencies -Funktionalität des Assembly-Plugins erhalten bleibt. Ich möchte möglicherweise in der Lage sein, die Quelldateien zu ändern und eine andere Version erstellen (z. B. ein Hotfix anwenden).
Also,
branch -Ziel, aber es löst externe Deps nicht in dem gewünschten Grad auf. Dies ist keine weit verbreitete Technik, aber Sie können immer Ihre spezifischen SNAPSHOT-Abhängigkeiten in Ihrem Projekt als "Projekt" -Repository überprüfen, wie in diesem Blogbeitrag beschrieben: Maven ist zu Ant wie ein Nagelgewehr ist zu einem Hammer
Kurz gesagt, verwenden Sie das Dependencies-Plugin, um das Repository zu erstellen, das sich in Ihrem Projektverzeichnis befindet . Das Folgende wird aus dem verlinkten Blogpost kopiert (den Sie lesen sollten):
1) Führen Sie mvn -Dmdep.useRepositoryLayout=true -Dmdep.copyPom=true dependency:copy-dependencies
"Dies erstellt / Ziel / Abhängigkeiten mit einem Repo-ähnlichen Layout aller Abhängigkeiten Ihres Projekts"
2) Kopieren Sie target/dependencies/ in etwas wie libs/
3) Fügen Sie Ihrem POM eine Repository-Deklaration wie die folgende hinzu:
%Vor%Sie machen dies zu einem automatisierten Teil Ihres Build / Release-Prozesses: Schritt 1, indem Sie das Dependencies-Plug-in für eine Lebenszyklusphasenphase konfigurieren und Schritt 2 mithilfe von AntRun-Plugin die heruntergeladenen Abhängigkeiten an die richtige Stelle verschieben.
Ich hoffe, das funktioniert für Sie. Ich muss jetzt duschen ...
Das maven Versionen Plugin wird das meiste von dem machen was du willst.
Sie werden es jedoch fast unbedingt in einem Pre-Build-Schritt ausführen müssen, in dem Sie alle Abhängigkeiten auflösen und die Pom-Datei entsprechend aktualisieren. Dann führe Maven (das den Pom erneut liest) erneut aus, um den echten Build auszuführen. Sie können möglicherweise alles innerhalb des Pom selbst konfigurieren, das mit einem separaten Ziel ausgelöst wird, wodurch ein separates Skript vermieden wird.
Dies funktioniert besser, wenn Sie bestimmte Versionen anstelle von SNAPSHOT-Abhängigkeiten verwenden und den Vorbereitungsschritt bei Bedarf aktualisieren lassen. Der einzige wirkliche Unterschied bei der Auflösung von Abhängigkeiten ist, dass Maven -SNAPSHOT-Abhängigkeiten immer wieder herunterlädt, während es nur normale Abhängigkeiten herunterlädt, wenn eine neue Version verfügbar ist. Allerdings behandeln viele Plugins (einschließlich des Versions-Plugins) -SNAPSHOT-Abhängigkeiten unterschiedlich, was zu Problemen führt. Da jedes CI-Build eine neue Versionsnummer hat, benutze ich nie -SNAPSHOT, sondern bevorzuge ein anderes Tag wie -DEV mit besser vorhersagbarem Verhalten für Dinge wie Entwickler lokale Builds etc.
Ich habe viel Zeit damit verbracht, Maven zu machen, um ähnliche Dinge zu tun. Die meisten Maven-Projekte, die ich kenne, haben eine Art Pre-Build-Schritt, um Versionsnummern festzulegen oder andere Einschränkungen wie diese zu umgehen. Der Versuch, all dies in einem Schritt zu tun, scheitert normalerweise, weil maven den pom nur einmal liest, die String-Substitution an einigen Stellen nicht funktioniert und der deployed / installed pom im Allgemeinen nicht die Ergebnisse der String-Substitution oder Änderungen enthält während des Builds.
Tags und Links maven maven-3 build-automation maven-plugin