Maven Versionsnummer aus SVN verwenden

[Tob]

Bei Maven scheine ich eine grundlegende Sache noch nicht zu verstehen. Aktuell schreibe ich in meine POMs immer genau rein mit welcher Version die Artefakte gebaut werden sollen:
[XML]
<groupId>com.firma.package</groupId>
<artifactId>Program</artifactId>
<version>2.0.0</version>
<packaging>jar</packaging>
<name>Program</name>
[/XML]
Mit dem Plugin buildnumber-maven-plugin lese ich aus SVN die aktuelle Revisionsnummer aus mit der dies Artefakt gebaut wurde und schreibe dies in die Manifestdatei um eine genaue Traceability herzustellen zwischen dem Artefakt und dem Stand des dazugehörigen Source Codes.

Zusätzlich würde ich gerne den dritten Teil der Versionsnummer (der inkrementelle Teil) mit der SVN Revisionsnummer versehen. Damit möchte ich folgendes erreichen:
1. Einmal um die Traceability zu vereinfachen,
2. aber auch um sicherzugehen, dass neuere Versionen der Artefakte wirklich in Artifactory deployed werden und das andere Maven oder Ant/Ivy Jobs wirklich die aktuellste Version nutzen.

Folgendes für das benennen der JAR Datei funktioniert:
[XML]
<build>
<finalName>Program-2.0-r${buildNumber}</finalName>
</build>
[/XML]

Aber in der POM Projectbeschreibung nicht. Hier wird die Propertie ${buildNumber} nicht aufgelöst.
[XML]
<groupId>com.firma.package</groupId>
<artifactId>Program</artifactId>
<version>2.0.${buildNumber}</version>
<packaging>jar</packaging>
<name>Program</name>
[/XML]

Den Punkt 2 könnte ich vielleicht mit dem verwenden von
[XML]
<version>2.0.0-SNAPSHOT </version>
[/XML] sicherstellen, würde ich aber gerne Vermeiden.
Weiß jemand ob meine Vorstellung umsetzbar ist und überhaupt mit den Maven Konzepten zusammenpasst?

 

[nillehammer]

Weiß jemand ob meine Vorstellung umsetzbar ist und überhaupt mit den Maven Konzepten zusammenpasst?

Das passt leider nicht. Die Version des Projekts ist bei Maven nur sehr bedingt dynamisierbar. Z.B. können children die Version des Parents referenzieren. Darüber hinsaus ist sie relativ statisch. Ein Umweg könnte über SVN-hooks möglich sein. Ähnlich dem Expanden von svn Variablen (z.B. $Rev$) im Quellcode. Aber solche hooks habe ich selbst noch nie benutzt.

 

[maki]

Bei Maven scheine ich eine grundlegende Sache noch nicht zu verstehen.

Warum es nciht so machen, wie normale Leute das normalerweise machen?

Für Snapshots nutzt man das -SNAPSHOT suffix, für alles andere richtige Release Versionen, diese werden in SVN getaggt und schon hat man seine Zuordnung.

Maven lebt von seinen Konventionen, da gibt es Konventionen für eigentlich alles, also: Lesen, lernen, anwenden.

 

[Tob]

Warum es nciht so machen, wie normale Leute das normalerweise machen?

Für Snapshots nutzt man das -SNAPSHOT suffix, für alles andere richtige Release Versionen, diese werden in SVN getaggt und schon hat man seine Zuordnung.

danke schon einmal für die Antworten.

Machen es wirklich alle Leute "normalerweise" so? Ich habe das Gefühl unserer Weg ist schon recht normal: Zu jedem Commit in das SVN bauen wir eine neue SoftwareVersion bei der wir mit Tests sicherstellen, dass sie korrekt funktioniert. Durch die hohe Testabdeckung gibt es nur für die monatlichen Versionen einen weiteren Qualitätscheck, der dann auch zu einer neuen Versionsnummer wird. Aber die Software die zwischen den monatlichen Sprints erzeugt wird, geht auch in die produktive Nutzung. Zwar nur für einen kleinen Teil, aber es muss Versioniert werden. Jetzt macht es aber aus unserer Sicht keinen Sinn bei einem voll automatisierten Prozess per Hand die Versionsnummer hoch zu zählen. Snapshot geht zwar, aber eine Versionsnummer wie 2.0.revisionsNummer, bei manchen Produkten 2.0.0.revisionsNummer wäre viel klarer.

Bei den ANT Projekten haben wir dies immer so gemacht und es klappte super. Daher dachte ich dieser Weg ist so normal, dass dies auch andere machen und mit Maven gehen müßte.

Das passt leider nicht. Die Version des Projekts ist bei Maven nur sehr bedingt dynamisierbar. Z.B. können children die Version des Parents referenzieren. Darüber hinsaus ist sie relativ statisch. Ein Umweg könnte über SVN-hooks möglich sein. Ähnlich dem Expanden von svn Variablen (z.B. $Rev$) im Quellcode. Aber solche hooks habe ich selbst noch nie benutzt.

Da könnte ich auch im Jenkins ein Ant Task als PreBuildJob laufen lassen und die POM per Hand editieren. Die Idee ist nicht schlecht, aber so frickelig, dass ich lieber einen sauberen Weg finden will und vielleicht dafür in Kauf nehme unsere Prozesse etwas anzupassen. Je nachdem wie sinnig es ist.

 

[maki]

Machen es wirklich alle Leute "normalerweise" so?

Ja, und nicht nur mit Maven

Ich habe das Gefühl unserer Weg ist schon recht normal: Zu jedem Commit in das SVN bauen wir eine neue SoftwareVersion bei der wir mit Tests sicherstellen, dass sie korrekt funktioniert.

Das ist auch ok (nehme an du meinst autom. Unit-/und Integrationstests), aber: Es handelt sich um SNAPSHOTS! Nicht um releases.
SNAPSHOTS sind per definition nicht eindeutig!!!

Durch die hohe Testabdeckung gibt es nur für die monatlichen Versionen einen weiteren Qualitätscheck, der dann auch zu einer neuen Versionsnummer wird.

Du meinst "Release". Ein "Release" ist das Geneteil von einem SNAPSHOT, ist eindeutig.
Schon mal, aufgefallen das Maven für Releases und SNAPSHOTS unterschiedliche Repositories nutzt?

Aber die Software die zwischen den monatlichen Sprints erzeugt wird, geht auch in die produktive Nutzung.

Ist doch super

Zwar nur für einen kleinen Teil, aber es muss Versioniert werden. Jetzt macht es aber aus unserer Sicht keinen Sinn bei einem voll automatisierten Prozess per Hand die Versionsnummer hoch zu zählen. Snapshot geht zwar, aber eine Versionsnummer wie 2.0.revisionsNummer, bei manchen Produkten 2.0.0.revisionsNummer wäre viel klarer.

2.0.revisionsNummer wäre kein SNAPSHOT sondern ein Release, während der Entwicklung hat man keine Releases sondern nur SNAPSHOTS... kurz: Man kann nicht an Releases arbeiten, sondern nur an SNAPSHOTS, nach dem releasen wird ein SNAPSHOT zum Release -> eindeutig aber "unveränderbar"

Bei den ANT Projekten haben wir dies immer so gemacht und es klappte super.

ANT? dann habt ihr kein Ivy genutzt
"Normales" Ant (ohne Ivy) hat kein Konzept für Artifakte zu denen Metadaten gehören, es waren alles nur Jars in irgendwelchen Verzechnissen die im CP landen.
Mit Maven, ANT + Ivy, Gradle, etc. pp. hat man eben Dependency Management, da braucht man eben Artifakte+Metadaten.
Da muss man eben auch zwischen SNAPSHOTS und Releaees unterscheiden (sollte man so aber auch).

 

[Tob]

ANT haben wir komplett ohne IVY eingesetzt und unsere MetaDaten selbst definiert um Artefakte zwischen den einzelnen Jobs hin und her zu schieben. Deswegen sind wir dabei in einem Projekt Maven zu testen und die anderen mit IVY zu erweitern. Denn auf dauer ging das garnicht :shock:

Ich verstehe komplett was Du meinst. Wenn ich so etwas drüber nachdenke, ist es vielleicht wirklich egal, welche Revision ein Snapshot in einer Artefakverwaltung hat, solange in der Software selber noch die Revision der Versionsverwaltung angegeben ist. Werde diesmal mal austesten und dann weiter schauen.

 

[maki]

Das SNAPSHOT/Release Konzept ist ziemlich starr in Maven, gehört zu den Grundmanifesten des Maven Dependencymanagements, da wirst du nix umkonfigurieren können.

Wenn das Konzept nicht auf eure Anforderungen passt, müsste man sich nach einem anderen Buildtool umsehen imho.

Revision etc. könnte ma ja per Keywordsubstitution in irgendwelchen Dateien wie MANIFEST opder einem Abiout Dialog etc. ersetzen, kann ja nützlich sein
Ist aber kein Ersatz für Metadaten fürs Dependencymanagement.

 

[DrLoad]

Finde das Thema sehr interessant, ich möchte nämlich gerade etwas ähnliches machen, steige allerdings noch nicht so ganz durch das snapshot/release Konzept von Maven durch. Überschneiden sich nicht viele Dinge, die im Releaseprozess gemacht werden mit Aufgaben, die von Jenkins übernommen werden? Also Jenkins checkt ja vom SCM System aus und stößt die Builds an, von Maven wird doch eigentlich nur der konkrete Build übernommen?
Ich lese schon eine Weile auf den Seiten des Maven release plugins (Guide to using the release plugin), habt ihr weitere empfehlenswerte Quellen zu dem Thema?

 

[maki]

In der maven doku wird release/snaptshot Konzept schon erklärt imho.
Verstehe nciht ganz was du meinst wenn du sagst das Maven und Jenkins sich überschneiden, Jenkins stösst Maven an, den Rest macht Maven(inklusive releasen, also SCM taggen, einen Release bauen und den Release in ein repo deployen), Jenkins direkt das SCM taggen bzw. "releasen" zu lassen geht an Maven vorbei und sollte imho nicht gemacht werden.

 

[DrLoad]

Interessant. Tatsächlich übernimmt bei uns zur Zeit Jenkins das Taggen und Deployment, da wir ein heterogenes Projekt haben, das auch aus Komponenten besteht (PHP, Flash), die von Maven in dieser Hinsicht nicht verwaltet werden können - dennoch gehören aber zu einem Release alle Komponenten zusammen.
Trotzdem hätte ich natürlich gern, dass sich die jar unseres Java Services nach dem aktuellen Tag sowie der Revisionsnummer benennen ließe und würde diese Informationen auch gern in die Mainfest Datei schreiben. Dabei bin ich auch auf den Konflikt oben gestoßen . Die Frage ist allerdings, ob das sinnvoll ist. Macht man das überhaupt so?

 

[maki]

Die Frage ist allerdings, ob das sinnvoll ist. Macht man das überhaupt so?

2 mal nein.

Warum steht schon oben, SNAPSHOTS und Releases gehören zu Maven.
Ob ihr dann beim ausliefern die Jars s umbenennt ist möglich aber ziemlich sinnfrei, es sollte ja schon ein tag im SCM geben und dann die Versionen in den Poms.

 

[kama]

Hallo,

Maven und SNAPSHOT's und Releases Versionen sind immer einen "Verwirrer" wert ;-)

Also ein Artefakt hat eine Version klar. Während der Entwicklung heißt die version "-SNAPSHOT" z.B. "1.2.3-SNAPSHOT"...(Erklärungen von maki).

Dabei wird immer hübsch fleißig in SVN eingecheckt...

Wenn man denn eine Release machen möchte (per Release Plugin in Maven) wird dann aus dieser Version "1.2.3" (OHNE -SNAPSHOT) und der SVN Tag wird zu "1.2.3" und die nächste Version wird zu "1.2.4-SNAPSHOT" (Wieder Entwicklung).
Das ist der Default Fall....

so wenn man nun die Infos über Version etc. im Manifest haben möchte, muss man dass eben einmal richtig angeben wie hier (parent pom oder Company POM):

        <plugin>
          <groupId>org.apache.maven.plugins</groupId>
          <artifactId>maven-jar-plugin</artifactId>
          <version>${maven.jar.plugin.version}</version>
          <configuration>
            <archive>
              <index>true</index>
              <manifest>
                <addDefaultImplementationEntries>true</addDefaultImplementationEntries>
                <addDefaultSpecificationEntries>true</addDefaultSpecificationEntries>
              </manifest>
              <manifestEntries>
                <artifactId>${project.artifactId}</artifactId>
                <groupId>${project.groupId}</groupId>
                <version>${project.version}</version>
              </manifestEntries>
            </archive>
          </configuration>
        </plugin>

Wenn man noch WAR's baut, dann muss man das auch für das WAR-Plugin einmal machen...

        <plugin>
          <groupId>org.apache.maven.plugins</groupId>
          <artifactId>maven-war-plugin</artifactId>
          <version>${maven.war.plugin.version}</version>
          <configuration>
            <archive>
              <index>true</index>
              <manifest>
                <addDefaultImplementationEntries>true</addDefaultImplementationEntries>
                <addDefaultSpecificationEntries>true</addDefaultSpecificationEntries>
              </manifest>
              <manifestEntries>
                <artifactId>${project.artifactId}</artifactId>
                <groupId>${project.groupId}</groupId>
                <version>${project.version}</version>
              </manifestEntries>
            </archive>
          </configuration>
        </plugin>

So genau genommen ist die Angabe der Revision von Subversion völlig unnötig, da durch die Version ja anhand eines Tags in Subversion referenziert wird (was nichts anderes ist als eine Revision)...

Was man noch machen kann ist mithilfe des BuildNumber Plugins die Revision Number aus dem SVN zu nehmen und die dann noch zusätzlich ins MANIFEST mit aufzunehmen, wenn man möchte...aber Notwendig ist die eigentlich nicht...

Machen es wirklich alle Leute "normalerweise" so?

Das Problem ist eben, dass es nicht alle Leute mit Maven so machen....Die Versuchen was anderes und fallen damit auf die Nase...und dann wird gemeckert, dass Maven sch.... ist....Wenn die sich an die Konventionen halten würden, hätten Sie keine Problem...

Zwar nur für einen kleinen Teil, aber es muss Versioniert werden. Jetzt macht es aber aus unserer Sicht keinen Sinn bei einem voll automatisierten Prozess per Hand die Versionsnummer hoch zu zählen. Snapshot geht zwar, aber eine Versionsnummer wie 2.0.revisionsNummer, bei manchen Produkten 2.0.0.revisionsNummer wäre viel klarer.

Dass kann man mithilfe des Release Plugins automatisieren...auch bei Maven....Dann kann man automatisch aus "2.0.0-SNAPSHOT" wird dann "2.0.0" bzw. "2.0.1-SNAPSHOT" usw.

Mann kann dem Release Plugin auch per Parameter mitteilen, welche Versionen man haben möchte...
Das Problem mit dem genannten Ansatz ist, dass es für Maven Release Versionen sind und keine SNAPSHOT's...

Interessant. Tatsächlich übernimmt bei uns zur Zeit Jenkins das Taggen und Deployment, da wir ein heterogenes Projekt haben, das auch aus Komponenten besteht (PHP, Flash), die von Maven in dieser Hinsicht nicht verwaltet werden können - dennoch gehören aber zu einem Release alle Komponenten zusammen.

Wie kommst Du darauf, dass die PHP, Flash Teile nicht mit Maven verwaltet werden können? Was muss denn da genau gemacht werden ? In ein ZIP Verpacken ? Ich würde hier ernsthaft prüfen, ob man das nicht doch mit Maven lösen kann...dann hat man es einheitlich...

Gruß
Karl Heinz Marbaise

 

[DrLoad]

Danke für die Antworten, hilft weiter

 

[Tob]

Auch von mir ein Danke an euren sehr guten Antworten. Wir haben dies Thema jetzt ausführlich diskutiert und getestet. Ergebniss: die Snapshotsache funktioniert wirklich gut und alle sind mit dieser Methode zufrieden.

 

[maki]

Tipp: Übe das Releasen auf einem Testrepo bevor du es wirklich brauchst, das Relase Plugin von maven ist recht komplex und cih kenne niemanden, der es beim ersten mal hinbekommen hat, kann ganz schön nervig sein weil es zwar im SCM tagt, aber dann beim releasen/deployen scheitert.

Das Maven Release Plugin ist zum Ziel einer richtigen hasstirade gegen Maven geworden, kannst ja mal danach Googlen

Also: Vorher Testen/Üben, nicht erst dann wenn man es dringend braucht.