Maven/Nexus - Automatisches Abhängigkeitsupdate

Question

Ich habe ein kleines Problem und frage mich, ob es einen Weg gibt, dies zu tun.

Im Wesentlichen behält mein Team einen "Kern" bei, der gemeinsamen Code enthält, der in allen unseren Projekten verwendet wird. Natürlich haben wir Maven verwendet, um es in unseren Projekten zu verwalten, aber ein Problem ist aufgetreten. Nach der Aktualisierung des "Kerns" haben wir Jenkins eingerichtet, um es zu erstellen und es in einem privaten Nexus-Repository bereitzustellen. Das alles funktioniert gut.

Das Problem, das ich habe, ist, dass diese Änderungen, die wir anwenden, in der Regel etwas hinzufügen, was wir vermissen oder etwas verschieben, das wir oft zum "Kern" umschreiben. Maven benötigt jedoch Zeit, um die Abhängigkeiten zu aktualisieren (es sei denn, wir löschen den lokalen Maven-Cache vollständig, was nicht ideal ist). Die Frage, die ich habe, ist, wie kann ich das erreichen, wo Maven "automatisch" ist (es könnte auf Knopfdruck oder die Verwendung eines Befehls sein [momentan wird versucht, es durch normale Methoden zu aktualisieren, wird es nicht aktualisiert]) Aktualisieren Sie das lokale Repository. Wir verwenden derzeit das Repository "Releases" anstelle der "Snapshots", aber natürlich können wir es bei Bedarf ändern.

Gibt es eine Möglichkeit, dies zu erreichen?

Answer 1

Die Verwendung der gleichen Version für ein aktualisiertes Artefakt verstößt gegen Mavens Erwartungen - die Version (Nicht-Snapshot) wird als endgültig und unverändert angenommen und sollte das assemblierte Artefakt eindeutig identifizieren. Das Ändern des Release-Versionscodes ohne Aktualisieren der Version kann zu irreparablen Builds führen!

Sie können stattdessen Snapshot-Versionen verwenden oder den Core als neue Version erstellen und die Abhängigkeiten entweder aktualisieren oder version range - wie [1.5,) verwenden.

---

Persönlich würde ich SNAPSHOT Versionen verwenden, wenn die Kern Änderungen oft und Projektmitteilungen relativ selten sind (beachten Sie sollten dann eine Release-Version des Core bauen, wenn Sie eine der je Projekte freigeben!), und würde jedes Mal ein neues Kern-Release mit neuer Version verwenden, wenn der Kern relativ stabil ist im Vergleich dazu, wie oft die abhängigen Projekte veröffentlicht werden.

Wenn Sie den Versionsbereich verwenden, um die Kernabhängigkeit zu definieren, sollten Sie den Bereich in den abhängigen Projekten aktualisieren, wenn Sie eine API-brechende Änderung im Kern vornehmen (wenn Sie dies tun, müssen die Projekte, die von der alten API abhängen, jetzt referenzieren) Versionsbereich, der kurz vor dieser neuen Version (oder der früheren Version anstelle des Bereichs) steht, und Projekte, die von der neuen API abhängig sind, müssen den Versionsbereich verwenden, der mit der aktuellen Version beginnt.

Answer 2

Wie schon andere sagen die Verwendung der Samve-Version für eine veränderte Artefakte macht nicht nur in Maven keinen Sinn. Wenn Sie eine Entwicklung auf Ihrer Kernkomponente durchführen, die von einer größeren Anzahl anderer Projekte verwendet wird, sollte Ihre Komponente eine normale Version haben, was bedeutet, dass Sie mit 1.0.0 beginnen. Einige Fehlerbehebungen finden Sie möglicherweise 1.0.1 oder eine andere Verbesserung, die Sie könnten nutze 1.1.0 usw. Also jetzt zu den aufwendigen Projekten. Dort können Sie versions-maven-plugin verwenden, um die Abhängigkeiten zu aktualisieren. Abgesehen davon, wenn Sie es in Mave richtig gemacht haben, haben Sie die Abhängigkeiten zum Kern an einem zentralen Ort über dependencyManagement definiert, wobei die Version nur ein einziger Ort sein sollte, was bedeutet, dass Aktualisieren einfach eine einzelne Zeile in einem Pom aktualisiert, so dass ich sehe kein echtes Problem hier und das kann auch über versions-maven-plugin getan werden und ein weiterer Schritt ist es, dies über einen jenkins-Job zu tun ... Und natürlich die Art und Weise während der schweren Entwicklung im Kern könnten Sie eine -SNAPSHOT Referenz verwenden .. .

Eine der Grundlagen in Maven und auch andere Tools wie das ist, dass eine Release-Version unveränderlich ist.