2012-06-07 8 views
5

Ich habe eine unternehmensweite Elternpom mit einem <dependencyManagement> Abschnitt, der die Versionen meiner Projekte definiert, die in meiner gesamten Anwendung verwendet werden sollten, von denen einige SNAPSHOTs sind, ein bisschen so:Maven Release Plugin nicht SNAPSHOTs in Abhängigkeitsverwaltung aktualisieren

<dependencyManagement> 
    <dependencies> 
    ... 
    <dependency> 
     <groupId>my.group</groupId> 
     <artifactId>myArtifact</artifactId> 
     <version>1.0-SNAPSHOT</version> 
    </dependency> 
    ... 
    <dependencies> 
</dependencyManagement> 

Wenn ich release:prepare auf dem übergeordneten Pom ausführen, werden diese SNAPSHOTs nicht entfernt. Das Ergebnis ist, dass die Projekte, die von dem übergeordneten Element erben, seine Versionen nicht verwenden können, wenn sie selbst freigegeben werden. Wie stelle ich sicher, dass der Abschnitt <dependencyManagement> des übergeordneten Pom aktualisiert wird, wenn ich veröffentliche?

Ich sah diese Frage: why does maven release plugin allow for SNAPSHOT version in dependency managment?, aber die genannten Tickets behaupten, in früheren Versionen des Plugins behoben werden.

Maven Release Plugin 2.3.1 
Apache Maven 3.0.4 (r1232337; 2012-01-17 08:44:56+0000) 
Java version: 1.6.0_31, vendor: Sun Microsystems Inc. 
OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows" 
+0

Ist die angegebene Abhängigkeit Teil Ihres Reaktors? – khmarbaise

+0

Nein, in diesem Fall ist es nicht. Das Eltern-Pom enthält keine darin deklarierten Module, da es in verschiedenen Projekten verwendet wird. Die Idee ist, Dinge zu zentralisieren, die allen unseren Projekten gemeinsam sind, wie beispielsweise Repositorys, Metadaten usw. Macht das einen Unterschied? – Conan

+0

Also, was ist dein wirkliches Problem? - Sie können Ihr eigenes Projekt nicht veröffentlichen? - Sie möchten den Plugin-Snapshot, wie er in JIRAs erwähnt wird? –

Antwort

1

Die maven-release-plugin betrifft nur die Überprüfung, ob Sie SNAPSHOT -s in Ihrem <dependencies/> Abschnitt haben. Die <dependencies/> wird von allen Modulen geerbt, die diese Eltern erweitern. Sie werden immer versuchen, diese Abhängigkeiten vor dem Erstellen aufzulösen.

Der Unterschied zwischen den Abschnitten <dependencies/> und <dependencyManagement/> besteht darin, dass Letzterer nur die Versionen definiert, die verwendet werden. Das heißt, das Release-Plugin ist überhaupt nicht betroffen, wenn Sie dort SNAPSHOT -s definiert haben, es sei denn, dieses übergeordnete Projekt ist ein Aggregator oder Teil eines Aggregators und dieser Elternteil wird als Ganzes mit dem Aggregator freigegeben.

In ähnlicher Weise kümmert sich das Maven-Release-Plugin nicht um . Ich glaube auch, dass es nur Maven-Eigenschaften anspricht, die Artefakt-Versionen enthalten, nur wenn diese sich auf <dependencies/> beziehen.

Der schlimmste Teil ist - soweit ich mich erinnere - Sie werden nicht einmal gewarnt, wenn eine Abhängigkeit/Plugin eine SNAPSHOT Version hat, wenn es in einem <*Management/> Abschnitt ist.

Aus diesem Grund ist der Ansatz, auf den ich zurückgegriffen habe, ein Eltern-POM mit <properties/> zu haben, das die Versionen der Artefakte enthält. Bevor ich es loslasse, scanne ich es für SNAPSHOT -s mit Hilfe von grep:

grep SNAPSHOT pom.xml 
+0

Ich habe tatsächlich die Versionen definiert in '' in der Elternpom, die dann im Abschnitt < verwiesen werden. Ich hatte gehofft, alle Versionen unserer internen Projekte in einem einzigen POM als SNAPSHOTs zu definieren und alle Versionen aus unseren verschiedenen Projekt-Poms zu behalten. Das hängt davon ab, dass der Eltern-Pom Release-Versionen im dependencyManagement spezifiziert, also denke ich, dass dies nicht funktionieren wird. Ich denke, ich muss die Versionsinformationen in jedes andere Projekt verschieben, was schade ist. Ich möchte vermeiden, dass ich die Versionen im Rahmen des Release-Prozesses manuell ändern muss. – Conan

+1

Was mich daran überrascht ist, dass, wenn ich ein bestimmtes Projekt vererbe, das Versionen aus dem ' Abschnitt des Elternteils erbt, dass es sich nicht über die SNAPSHOTs beschwert. Es scheint, dass, wenn die Versionen in den veröffentlichten Poms nicht erwähnt werden, das Release-Plugin sie einfach loslassen kann, anstatt die SNAPSHOTs zu entfernen. – Conan

+1

Ich bin traurig, dass ' sich so verhält, aber es scheint von Entwurf zu sein, also akzeptiere ich diese Antwort. Vielen Dank für Ihr Feedback! – Conan

1

Sie versuchen also, Artefakte freizugeben, die nicht Teil des Builds sind, den Sie vorbereiten? Wenn Sie eine Relase erstellen: durchführen, welche Artefakte sollte das Plugin in das Repository hochladen, wenn sie nicht existieren? (Wenn ja, warum stellst du die Snapshot-Version?).
Ich denke, wie @khmarbaise sagte, das Plugin wird SNAPSHOTS nicht entfernen, die nicht Teil Ihres Reaktors sind (das Plugin könnte denken, dass sie Abhängigkeiten von Drittanbietern sind).

Dies ist ein Kommentar, ich habe es als Antwort, weil ich nicht 'Reputation haben, um Kommentare noch ... und Entschuldigung für mein Englisch!

+0

Ja, in diesem Szenario gebe ich nur ein Eltern-Artefakt mit 'Pom'-Verpackung heraus. Das einzige Artefakt, von dem ich erwarte, dass es zu diesem Zeitpunkt hochgeladen wird, ist das Eltern-Pom. Wenn es darum geht, ein bestimmtes Code-enthaltendes Projekt tatsächlich freizugeben, wird es von dem freigegebenen Elternteil erben und folglich die Versionen verwenden, die in seinem Abschnitt definiert sind; wenn sie SNAPSHOTs enthalten, ist meine Freilassung in einem zweifelhaften Zustand, in dem ich nicht darauf vertrauen kann, dass es in Zukunft wiederverwendbar ist. – Conan

+0

PS Ihr Englisch ist ausgezeichnet: D – Conan

+0

Als Workaround, wenn der Zweck der Freigabe nur SNAPSHOT auf DependencyManagement und Commit zu SCM ersetzen, sollten Sie versuchen, nur diesen Prozess manuell zu tun (oder besser einen Batch-Prozess), nicht manuell ändern die Versionen für jedes Projekt, komm Don gib auf !. Versuchen Sie Folgendes (in einer .bat-Datei): sed -i 's/-SNAPSHOT // g' pom.xml; cvs commit pom.xml. Sie können GnuWin für sed-Funktionalität verwenden, oder besser, starten Sie Linux! –

Verwandte Themen