So vermeiden Sie die spezifischen Feature-Versionen in Eclipse-Zieldefinitionen

9

Ich habe ein osgi-Projekt, das in drei Repositories aufgeteilt ist. Jedes Repository hat seinen eigenen Build in p2 repository mit Tycho:

%Vor%

Jedes Repository hat auch eine Zieldefinitionsdatei, die die Pakete aus den p2-Repositories von Drittanbietern und aus anderen Projekt-Repositories enthält (P2-Repo1, P2-Repo2 oder P2-Repo3 oben). Repo2 enthält eine Abhängigkeit von Repo1-Bundles, Repo3 hat Abhängigkeiten zu den Repo1- und Repo2-Bundles:

%Vor%

Jetzt habe ich folgendes Problem. Nach dem Erstellen des ersten Repositorys wurde das P2-Repo1-Repository aktualisiert und enthält das Feature mit den neuen Snapshot-Versionen. Die Zieldefinitionen von Repo2 und Repo3 hängen von der vorherigen Snapshot-Version der Repo1-Bundles ab, und das Erstellen dieser Repositories ist ohne Aktualisierung der entsprechenden Zieldefinitionen unmöglich (In Eclipse gibt es die Schaltfläche Aktualisieren im Ziel-Editor).

%Vor%

Es ist also unmöglich, alle drei Repos automatisch zu erstellen, so dass der Build-Prozess zu kompliziert wird:

  • Übernehmen Sie die Änderungen im ersten Repo und erstellen Sie sie mit Jenkins
  • Aktualisieren Sie die Zieldefinition von repo2, um sie auf die neue Version von Repo 1-Feature
  • zu verweisen
  • Übernehmen Sie dieses Update in Repo2 und erstellen Sie es mit Jenkins

usw. ....

Ich denke jetzt, git Submodule für die Integration dieser 3 Repos zu verwenden, um die p2-Repositories zu vermeiden oder alle in einem Repository zu verschieben.

    
Ivan 11.11.2015, 07:59
quelle

1 Antwort

7

Version auf 0.0.0 setzen

Ich weiß nicht, wie ich die .target -Datei mit dem Target Editor bearbeiten kann, aber Sie können eine Versionsnummer von 0.0.0 in der Zieldatei durch Bearbeiten in XML oder Text Editor, wie folgt:

%Vor%

Durch Angabe einer Versionsnummer von 0.0.0 in der Zieldatei sollten Sie die neueste Version der Einheit aus dem p2-Repository abrufen.

Das heißt, es gibt schwerwiegende Nachteile der Verwendung dieser faulen (mehr über den Namen unten) Art der Angabe von Versionen. Es macht es sehr schwierig, ältere Versionen Ihres Projekts wiederherzustellen, da die ältere Version die neueste Version der Abhängigkeit vom p2-Repository anstelle der korrekten Version einholt.

Verwenden Sie Zielplattform Definition DSL und Generator

Verwenden Sie anstelle der Bearbeitung mit dem Zieleditor die ausgezeichnete "Zielplattform-Definition DSL und Generator" stattdessen. Es ermöglicht Ihnen, die Zieldateien sinnvoller zu bearbeiten. In diesem Fall können Sie das Schlüsselwort lazy version verwenden, um 0.0.0 als Versionsnummer anzugeben. Es würde so aussehen:

%Vor%

Das Beste aus beiden Welten

Der Generator kann über den Befehl aufgerufen werden Zeile (z. B. aus pom.xml), sollten Sie die Versionsnummer in der .tpd -Datei weglassen. Wenn keine Versionsnummer in der .tpd -Datei vorhanden ist, weist die generierte .target -Datei die aufgelöste Versionsnummer auf die neueste Version auf. Wenn Sie die generierte .target -Datei als Teil Ihrer Build-Artefakte aufbewahren, können Sie ältere Versionen Ihrer Software anhand der richtigen Abhängigkeiten neu erstellen.

    
Jonah Graham 15.11.2015 09:51
quelle

Tags und Links