Maven deploy geändert Artefakte nur

Question

Ich verwende Maven 2.2 mit Nexus 1.4.0

Lassen Sie uns sagen, dass ich eine Pom-Struktur wie diese haben (mit entsprechenden Versionen)

parentproj, v1.0.1 
- childproj1, v1.0.2 
- childproj2, v1.0.7 

childproj1 und childproj2 verschieden sind Teile der Anwendung (zB GUI und Backend) und ich möchte ihre Versionen getrennt halten können, damit ich eine neue Version des Backends veröffentlichen kann, ohne eine neue Version der GUI veröffentlichen zu müssen.

, nun diese Struktur zu implementieren es

mvn parentproj und sagen bequem zu gehen wäre zu Nexus einsetzen -DperformRelease = true

, die alle Artefakte auf dem Nexus realease Repository bereitstellen würde . Dies funktioniert gut, das erste Mal, dass ich es einsetzen, aber das zweite Mal, dass ich auf Probleme stoßen: Lassen Sie uns sagen, dass ich ein Update auf childproj1 gemacht, so dass wir jetzt die folgenden Versionen:

parentproj, v1.0.1 
- childproj1, v1.0.3 
- childproj2, v1.0.7 

In dieser Situation Nexus wird nicht lass mich mvn deploy von parentproj machen, da es bereits eine Kopie von childproj2 in der Version 1.0.7 hat. Nexus wird sagen "Ressource, illegale Anfrage: Repository mit ID = 'Releases' erlaubt keine Aktualisierung von Artefakten." Das ist in Ordnung, ich möchte die bestehenden Versionen nicht versehentlich aktualisieren.

Aber ich denke, was ich tun möchte, ist in der Lage zu sagen Maven etwas wie "nur die Artefakte bereitstellen, die Versionen haben, die nicht bereits im Release-Repository vorhanden sind".

Gibt es eine Möglichkeit, dies zu tun, oder müsste ich jedes Projekt selbst bereitstellen?

Answer 1

Nach meiner Erfahrung war es einfacher, alles zu implementieren, und oft verwenden Sie die gleiche Versionsnummer für alle Komponenten. Wenn mein Team beispielsweise an Version 1.0.7 arbeitet, haben alle Submodule die Versionsnummer 1.0.7-SNAPSHOT, bis wir sie freigeben, auch wenn sich in bestimmten Modulen kein Code geändert hat. Bei der Bereitstellung würden wir dann die gesamte Anwendung bereitstellen. Ich denke, es hat mehrere Vorteile gegenüber einer stückweisen Bereitstellung. Erstens, wenn Sie alle auf die letzte stabile Version zurücksetzen müssen, müssen Sie nur für alle Module auf 1.0.6 zurücksetzen. Sie müssen sich nicht daran erinnern, dass das Backend 1.0.3 war, während die GUI 1.0.6 war. Zweitens wird sichergestellt, dass alle Komponenten korrekt miteinander kompiliert und als logische Gruppe getestet wurden.

Sorry, ich weiß, das ist nicht eine bestimmte Antwort auf Ihre Frage, aber zumindest im Fall meines Teams war es nützlich, etwas anders zu denken

Answer 2

Ich würde vorschlagen, dass, wenn Sie zu halten, planen, bauen Wenn Sie die Module unabhängig voneinander bereitstellen, sollten Sie in Erwägung ziehen, separate CI- und mvn deploy Jobs für jedes einzurichten. Mit unabhängigen mvn deploy Jobs erhalten Sie das Verhalten, das Sie aus der Box suchen. Dies bedeutet, dass Sie den Aggregator pom (parentprj) nicht verwenden müssen, um diese Module zu erstellen und bereitzustellen.

Wenn Sie alles aus dem Aggregator pom machen möchten, wie Build und Deploy, dann würde ich vorschlagen, Johns Antwort zu folgen und alle Versionsnummern synchron zu halten.

Es hängt nur davon ab, wie Ihr Team die Codebasis betrachten möchte.Wenn Sie die Dinge in einer wirklich modularen Weise halten wollen, sollten Sie Ihre maven-Module wie Bausteine ​​verwenden und sie anders behandeln, bis Sie bereit sind, die ganze App zusammen zu stellen. Wenn Ihre App eher monolithischer Natur ist, behandeln Sie sie so und halten Sie sie synchron. Das bedeutet nicht, dass Sie immer noch keine separaten Maven-Module zur Aufrechterhaltung der Code-Basis-Modularität ausbrechen können, sondern erkennen, dass sie keinen Wert außerhalb des Kontexts Ihrer größeren App haben.

Ein guter Weg, diese Entscheidung zu treffen, ist die Frage: Werden andere Projekte/Apps dieses Modul als Abhängigkeit bezeichnen müssen? Wenn dies der Fall ist, sollten Sie es unabhängig voneinander erstellen, versionieren und bereitstellen. Wenn nicht, sehe ich keine Probleme, die Versionen miteinander in Einklang zu bringen.

Answer 3

Zunächst einmal denke ich, dass Sie zwischen übergeordneten Projekt und Aggregationsprojekt unterscheiden sollten. Übergeordnete Projekte sollten für die Einstellungen verwendet werden, die mehreren Projekten gemeinsam sind, z. Versionen der Abhängigkeiten; Aggregationsprojekte sollten verwendet werden, um gleichzeitig eine Gruppe von Projekten aufzubauen, z. eine Reihe von Gläsern und der Krieg, der sie einschließt.

Die zwei Arten von Projekten werden am besten getrennt gehalten. Das übergeordnete Projekt ändert sich normalerweise nicht sehr oft und wenn es das tut, ist es normalerweise am besten, neue Versionen aller Projekte zu veröffentlichen, die davon abhängen; Der einzige Zweck des Aggregationsprojekts besteht darin, die Erstellung einer Reihe von Projekten voranzutreiben. Daher sollte sich die Versionsnummer wahrscheinlich ändern, wenn eines der darin enthaltenen Projekte freigegeben werden muss. Wenn Sie Eltern vom Aggregator getrennt haben, können Sie besser entscheiden, ob Sie dem Ratschlag von John Paulett folgen und alles unter der gleichen Versionsnummer behalten oder versuchen, die Versionsnummer jedes Projekts nur dann zu ändern, wenn dies tatsächlich erforderlich ist Lass es los. Die erste Option ist einfacher und weniger fehleranfällig, verursacht jedoch die Freigabe neuer Versionen von Bibliotheken, die nicht geändert wurden. Dies ist unter Umständen nicht akzeptabel, wenn Sie zum Beispiel Patches und keine vollständigen Versionen versenden müssen. Die zweite Option ist komplizierter und fehleranfälliger, verursacht jedoch, dass Ihre Versionsnummern mit der Entwicklung Ihrer Software übereinstimmen. Das Maven-Release-Plugin und das Jenkins-Tool für die fortlaufende Integration können dort hilfreich sein. Ich denke, Sie sollten sie überprüfen. Sehen Sie auch, ob Sie Maven auf mindestens Version 2.2.1 und Nexus auf eine neuere Version aktualisieren können.

Answer 4

Offensichtlich wird dieses Bedürfnis von Maven weder von Nexus noch von Archiva angesprochen. Jetzt kann es nur durch zusätzliche Tricks, die vom Build-Manager eingerichtet wurden, wie in den vorherigen Posts beschrieben, behoben werden.

In einer idealen Welt

• würde der pom
  umfassen. sowohl die Release-Version als auch die Snapshot-Version des Moduls
  . eine Definition der Dateien, die bei Änderung die Verwendung der Snapshot-Version
  rechtfertigen. das Source-Control-Management-System anhand des freigesetzten Modul
  

• abhängigen Module Poms in dem entsprechenden Abhängigkeitsabschnitt die Release-Version Info so neben der Snapshot-Version Info hinzufügen würde, dass es zu der Snapshot-Bibliothek verknüpft, wenn in der Repo und die Freigabe Bibliothek sonst
  

• der maven-Reaktor wäre eine Option, um zu lesen sowohl die Abhängigkeitshierarchie und die Datei ändert info (scm diff) zu wissen, ob ein bestimmtes Modul verwendet wird in seiner Veröffentlichung oder Snapshot-Version ist .

• Das Release-Plugin würde standardmäßig die Freigabe der Module überspringen, die immer noch mit ihrer Release-Version basierend auf den Dateiänderungen und den Abhängigkeitsinformationen verwendet werden können.