Maven buildnumber-maven-plugin / Formatproblem mit timestamp

[Sergeant_Pepper]

Hallo,

dies ist eine Versionsdatei als Resource:

version=${project.version}
build=${buildNumber}-${timestamp}

Daraus soll durch Resourcen-Filterung das entstehen:

version=0.3.0-SNAPSHOT
build=767-16.01.2013

Tatsächlich kommt das heraus:

version=0.3.0-SNAPSHOT
build=767-1358326184903

Warum ist der Timestamp nicht formatiert??? Ich habe die Infos in diesen URLs verwendet:Stamping Version Number and Build Time in a Properties File with Maven | Rob's Blog und maven 2 - Adding the current date with Maven2 filtering - Stack Overflow
Dies steht im Effective POM des Projekts:[XML] <properties>
<timestamp>${maven.build.timestamp}</timestamp>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<maven.build.timestamp.format>dd.MM.yyyy</maven.build.timestamp.format>
</properties>

<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>buildnumber-maven-plugin</artifactId>
<version>1.1</version>
<executions>
<execution>
<phase>validate</phase>
<goals>
<goal>create</goal>
</goals>
<configuration>
<doCheck>true</doCheck>
<doUpdate>true</doUpdate>
</configuration>
</execution>
</executions>
<configuration>
<doCheck>true</doCheck>
<doUpdate>true</doUpdate>
</configuration>
</plugin>
[/XML]

Die Properties und das buildnumber-Plugin sind in einem Firmen-POM definiert. Wenn ich das testweise in das Projekt-POM übertrage, funktioniert es auch nicht.

 

[kama]

Hi,

also mal abgesehen von der Sinnhaftigkeit eine Buildnumber etc. in eine Resource Datei abzulegen...
Besser wäre hier die MANIFEST.MF Datei zu nutzen aber unabhängig davon muss man selbstverständlich auch eine Konfiguration für den Timestamp angeben.


Build Number Maven Plugin - Usage

[xml]
<configuration>
<format>{0,date,yyyy-MM-dd HH:mm:ss}</format>
<items>
<item>timestamp</item>
</items>
</configuration>
[/xml]


[xml]
<project>
...
<build>
<pluginManagement>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>2.4</version>
<configuration>
<archive>
<manifestEntries>
<buildNumber>${buildNumber}<buildNumber>
<timestmap>${timestamp}</timestamp>
<...>..</...>
</manifestEntries>
</archive>
</configuration>
...
</plugin>
</plugins>
</pluginManagement>
</build>
...
</project>
[/xml]

Genaueres unter Manifest Entries

 

[Sergeant_Pepper]

habe jetzt hier (Jenkins) eine Lösung gefunden (obwohl ich nicht mit Jenkins arbeite):

Es wird die Property

${build.timestamp}

statt

${timestamp}

verwendet, sowohl in der Resource als auch im Abschnitt

<properties>

im POM.

[XML] <properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<build.timestamp>${maven.build.timestamp}</build.timestamp>
<maven.build.timestamp.format>dd.MM.yyyy HH:mm</maven.build.timestamp.format>
</properties>
[/XML]

 

[Sergeant_Pepper]

Hallo Kama ...

danke für die Infos.

abgesehen von der Sinnhaftigkeit eine Buildnumber etc. in eine Resource Datei abzulegen

ich möchte im Logging der Anwendung die Buildnummer, und daher lese ich die Resource beim Programmstart ein.

Die von dir genannte Homepage kenne ich, und ich habe am Anfang das hier gemacht:
[XML] <configuration>
<doCheck>true</doCheck>
<doUpdate>true</doUpdate>
<format>{0}-{1,date,yyyy-MM-dd}</format>
<items>
<item>buildNumber</item>
<item>timestamp</item>
</items>
</configuration>
[/XML]
Damit wird ein String gebaut, der eine Buildnummer und das Datum enthält.
Es wird aber nicht die Revisions-Nr. von Subversion verwendet, und das will ich unbedingt. Und trotz doCheck=true wird das Projekt gebaut, obwohl nicht nach SVN eingecheckt wurde.

Irgendwie scheint

<format>

das

<doCheck>true</doCheck>

auszuschließen. Unschön.

 

[kama]

Hi,

nimm auch mal die aktuelle Version 1.2 vom buildnumber-maven-plugin...

Abgesehen davon macht eine Build nummer keinen Sinn...die version ist eigentlich das wichtige...

Gruß
Karl-Heinz Marbaise

 

[Sergeant_Pepper]

Abgesehen davon macht eine Build nummer keinen Sinn...die version ist eigentlich das wichtige...

na, daran beißen wir uns wohl fest 🙂 Ich finde, wenn die Buildnummer eine SVN-Revision widerspiegelt, macht sie viel Sinn. Ich vergaß zu erwähnen, dass wir auch tlw. SNAPSHOT-Versionen nahezu produktiv einsetzen (keine Software, die an Kunden verkauft wird, alles interne Nutzung).

Danke für die Info zur Version 1.2

 

[kama]

Hi,

na, daran beißen wir uns wohl fest 🙂 Ich finde, wenn die Buildnummer eine SVN-Revision widerspiegelt, macht sie viel Sinn. Ich vergaß zu erwähnen, dass wir auch tlw. SNAPSHOT-Versionen nahezu produktiv einsetzen (keine Software, die an Kunden verkauft wird, alles interne Nutzung). Danke für die Info zur Version 1.2

Das ist ein Grundlegender Fehler bei der Verwendung von Maven...leider oft gesehen...

dazu gibt es eben die Version und das Release plugin....

Auch bei einer internen Software Software muß man nachhalten was geändert wurde etc. sprich Milestones etc. (Version 1.0, 1.1, 1.3 etc.) somit hier auch releases (anstatt SNAPSHOT's)...Somit vermute ich auch, dass Ihr im SVN keine Tags macht ? Hm... Wie macht Ihr dann sauber Bug Fixing ? Ohne Branches nehme ich an ?

Die Build Nummer / SVN Revision Nummer etc. ist nur eine Krücke (abgesehen davon das die recht schlecht ist), um genau das zu erreichen was man eigentlich viel einfacher mit Maven und dem Release Plugin erreichen kann....

Weiterhin ist das Problem im Repository Manager, dass man da nicht aufräumen kann ...mit Releases kann man alle SNAPSHOT's weg werfen...nur die Releases bleiben übrig usw.

Gruß
Karl-Heinz Marbaise

 

[Sergeant_Pepper]

du wirst lachen, wir setzen das Release-Plugin ein, inkl. Tagging in Subversion ...

Ich will nun nicht in die Tiefe gehen, warum und weshalb wir oft Snapshots einsetzen. Klar, die reine Lehre sagt was anderes.
Es gibt Anforderungen, die wir nur mit Echtdaten testen können. Da wird mal was mit einem Snapshot probiert, dabei entsteht ein Logging. Dann will ich sicher sein, dass ich die Source-Version identifizieren kann. Warum meinst du, dass die Revision als Buildnummer eine Krücke ist?

Fehlerbehebung machen wir noch nicht mit Branches, sondern im trunk. Wir üben noch ;-)

 

[maki]

Ich will nun nicht in die Tiefe gehen, warum und weshalb wir oft Snapshots einsetzen. Klar, die reine Lehre sagt was anderes.

Nicht die "reine Lehre", sondern Logik sagt was anderes.
Das gehört zu den Maven Grundlagen.
Wenn man einen Snapshot released, hat man danach keinen Snapshot mehr, sondern ein Release 😉

Die Revision identifiziert man über die Version bei Releases, denn das ist eindeutig.
Snapshots dagegen macht man auch mit Revisions nicht eindeutig identifizierbar, falls doch, hat man sowieso wieder ein Release, die ganze Übung ist also ziemlich Sinnfrei und verstösst gegen die Maven Konventionen.
Die ganze "Revision in die Version schrieben" Geschichte willst du ja nur einbauen um die Snapshots die du released eindeutig zu machen -> Krücke, weil du den eigentlichen Fehler (deployen von Snapshots) wieder durch einen anderen Fehler auszugleichen 😉

Siehe auch was Maven3 beim deployen von Snapshots macht...

 

[Sergeant_Pepper]

Siehe auch was Maven3 beim deployen von Snapshots macht...

meinst du damit, dass Maven für jeden Snapshot im Repository eine Version mit Zeitstempel anlegt?

 

[maki]

meinst du damit, dass Maven für jeden Snapshot im Repository eine Version mit Zeitstempel anlegt?

Ja.

https://cwiki.apache.org/MAVEN/mave...mpatibilityNotes-NonuniqueSnapshotDeployments

 

[Sergeant_Pepper]

Nicht die "reine Lehre", sondern Logik sagt was anderes.
Das gehört zu den Maven Grundlagen.

... die ganze Übung ist also ziemlich Sinnfrei und verstösst gegen die Maven Konventionen.

Warum bietet Maven an, Snapshots zu deployen?

Wenn man einen Snapshot released, hat man danach keinen Snapshot mehr, sondern ein Release

Nach meinem Verständnis kann man einen Snapshot mit dem Release-Plugin gar nicht releasen.

Ich deploye den Snapshot ja auch deshalb, damit mein Kollege, der das Projekt auch nutzt, die Änderungen sehen kann.

 

[maki]

Warum bietet Maven an, Snapshots zu deployen?

Manchmal braucht man das eben, große Teams, verschiedene "Subteams" die sich Artifakte bereitstellen müssen, etc. pp., sagst du ja selber auch:

Ich deploye den Snapshot ja auch deshalb, damit mein Kollege, der das Projekt auch nutzt, die Änderungen sehen kann.

Nach meinem Verständnis kann man einen Snapshot mit dem Release-Plugin gar nicht releasen.

Du meinst wohl eher dass man Projekte, die SNAPSHOT Abhängikeiten aus anderen Projekten haben nicht releasen kann.
Ansonsten ist es vollkommen normal aus SNAPTSHOT Versionen des eigentlichen Projektes Release Versionen zu machen, durch das release plugin.

Wie dem auch sei, wenn du anfängst deine eigene Versionslogik (Buildnummer, SVN Revision, etc. pp.) einzuführen, verstösst du nicht nur gegen Maven Konventionen und Prozesse, sondern du arbeitest auch aktiv gegen Maven, und Maven aktiv gegen dich 😉

 

[Sergeant_Pepper]

Danke für eure Geduld.

Du meinst wohl eher dass man Projekte, die SNAPSHOT Abhängikeiten aus anderen Projekten haben nicht releasen kann.

richtig, ist mir bekannt

Ansonsten ist es vollkommen normal aus SNAPTSHOT Versionen des eigentlichen Projektes Release Versionen zu machen, durch das release plugin.

richtig. Im Zuge der Ausführung des release-plugins wird aus dem Snapshot ein Release.

Ich habe ja auch nie gesagt, dass ich einer Snapshot-Version den Status eines Releases zukommen lassen will. Das wir einen Snapshot unter Produktionsbedingungen einsetzen, steht auf einem anderen Blatt.

Wie dem auch sei, wenn du anfängst deine eigene Versionslogik (Buildnummer, SVN Revision, etc. pp.) einzuführen, verstösst du nicht nur gegen Maven Konventionen und Prozesse, sondern du arbeitest auch aktiv gegen Maven, und Maven aktiv gegen dich 😉

nein, das stimmt so gar nicht. Ich entwickle keine eigene Logik der Maven-Versionierung. Es gibt Versionen die "1.0.5" oder vorher "1.0.5-SNAPSHOT" heißen. Ich halte mich 100%-ig an die Konventionen der Maven-Versionierung, und will die Buildnummer einfach nur im Logging ausgeben können.
Siehe Start des Themas.

Das buildnumber-maven-plugin bietet von Haus aus die Möglichkeit, eine Subversion-Revision als Buildnummer zu verwenden. Das ist also keine exotische oder abwegige Anforderung von mir !!!
Die Probleme kamen nur hoch, weil ich zusätzlich das Build-Datum haben will - im Logging, nicht in einer Versionsbezeichnung.

 

[kama]

Hi,

Ich will nun nicht in die Tiefe gehen, warum und weshalb wir oft Snapshots einsetzen. Klar, die reine Lehre sagt was anderes.

Siehe Kommentare von maki etc. Praxis und Erfahrung zeigt, das da was Faul ist...

Es gibt Anforderungen, die wir nur mit Echtdaten testen können. Da wird mal was mit einem Snapshot probiert, dabei entsteht ein Logging. Dann will ich sicher sein, dass ich die Source-Version identifizieren kann. Warum meinst du, dass die Revision als Buildnummer eine Krücke ist?

Wenn Ihr in einer Produktiven Umgebung eine SNAPSHOT version ein setze dann springe ich nur von der Brücke ;-(

Hier ist genau der Fehler. Dann solltet Ihr besser so Sachen machen wie 1.0.1-RC1, 1.0.1-RC2 etc. Damit hast Du aus Maven sicht eine Release und kannst ganz genau Nach vollziehen welcher Stand da ist und somit auch für Bug Tracking Systeme nachzuvollziehen...etc...daraus folgt, dass der Ganze Käse mit Buildnummer usw. nicht notwendig ist...

Fehlerbehebung machen wir noch nicht mit Branches, sondern im trunk. Wir üben noch

Noch ein Fehler....wo entwickelt ihr die nächsten Releases etc. ? auch im Trunk ? autsch ...

nein, das stimmt so gar nicht. Ich entwickle keine eigene Logik der Maven-Versionierung. Es gibt Versionen die "1.0.5" oder vorher "1.0.5-SNAPSHOT" heißen. Ich halte mich 100%-ig an die Konventionen der Maven-Versionierung, und will die Buildnummer einfach nur im Logging ausgeben können.

Wozu braucht man denn eine Buildnummer wenn man Releases hat...sprich die Verison 1.4.3 und gut ist...
Abgesehen, dass Deine "Buildnummer" keine wirkliche Buildnummer ist sondern die SVN revision...um Eindeutig zu sein musst immer in Subversion auch noch das Verzeichnis kennen. Somit kommen wir wieder zur artifactId und groupId ...was aber auch nicht hilft...Korrekt wäre es die Version zu nehmen + GroupId/ArtifactId und in der pom.xml gehört dann ein entsprechender SCM Tag und damit kann ich dann sehen wo das im SVN zu finden ist...


Da es ja zu einer Release auch einen SVN Tag mit entsprechender Bezeichnung gibt ist das Ganze unnötig usw...Im Logging eine Build nummer macht überhaupt keinen Sinn...über die Version würde ich schon nachdenken. Denn eigentlich habe ich einen Log Datei und darin ein Datum (aktuelle Zeit) und mehr brauche ich nicht...Ich weiß welche Release auf einem System installiert habe...

Benutzt Ihr einen Repository Manager ?

Gruß
Karl-Heinz Marbaise

 

[Sergeant_Pepper]

vielen Dank für eure Hilfe.

Ich habe bereits geschrieben, dass mir das Manko des Snapshots-Einsatzes bewusst ist. Ich habe auch geschrieben, dass es dafür Gründe gibt, die ich hier nicht ausführen möchte.

Es ging rein um die Verwendung des buildnumber-maven-plugins.

Habt ihr noch nie bewusst gegen Konventionen verstoßen? Hut ab ...

Benutzt Ihr einen Repository Manager ?

Wir setzen Nexus ein.

Fehlerbehebung machen wir noch nicht mit Branches, sondern im trunk. Wir üben noch

Noch ein Fehler....wo entwickelt ihr die nächsten Releases etc. ? auch im Trunk ? autsch ...

Ich habe geschrieben, "wir üben noch". Damit wollte ich ausdrücken, dass mir das Defizit bewusst ist. Wir sind in einem Lernprozess.

Und ich habe auch schon geschrieben, dass wir unsere Software ausschließlich intern einsetzen. Damit wollte ich sagen, dass man bei externe Verwendung, sprich Vermarktung, sicher andere Maßstäbe anlegen muss.

 

[bmaehr]

Sorry, dass ich den alten Thread hervorhole, aber das kann ich einfach nicht so stehen lassen.

Hi,
Das ist ein Grundlegender Fehler bei der Verwendung von Maven...leider oft gesehen...

dazu gibt es eben die Version und das Release plugin....

Der grundlegende Fehler ist, dass die Versionsauflösung von Maven und das Release-Plugin völlig kaputt und für den praktischen Einsatz ungeeignet sind.

Und dann braucht man sich nicht wundern, wenn Workarounds drum herum entwickelt werden.

Und obwohl ich seit Jahren maven in den verschiedensten Projekten einsetze muss ich sagen: Maven verhindert oft den Einsatz von Best-practices - insbesondere auch durch Maven-Entwickler, die sich und ihren eigenen Horizont als das Maß aller Dinge sehen.

 

[bmaehr]

habe jetzt hier (Jenkins) eine Lösung gefunden (obwohl ich nicht mit Jenkins arbeite):

Es wird die Property

${build.timestamp}

statt

${timestamp}

verwendet, sowohl in der Resource als auch im Abschnitt

<properties>

im POM.

[XML] <properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<build.timestamp>${maven.build.timestamp}</build.timestamp>
<maven.build.timestamp.format>dd.MM.yyyy HH:mm</maven.build.timestamp.format>
</properties>
[/XML]

Eine andere funktionierende Lösung, die ich lange Zeit verwendet hatte:
[XML] <plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<version>1.6</version>
<executions>
<execution>
<phase>generate-resources</phase>
<goals>
<goal>run</goal>
</goals>
<configuration>
<tasks>
<!-- Safety -->
<mkdir dir="${project.build.directory}"/>
<tstamp>
<format property="build.time" pattern="yyyy-MM-dd hh:mm:ss"/>
</tstamp>
<tstamp>
<format property="build.nr" pattern="yyyyMMddhhmmss"/>
</tstamp>
<echo file="${basedir}/target/filter.properties">
buildNr=${build.nr}
buildTime=${build.time}
</echo>
</tasks>
</configuration>
</execution>
</executions>
</plugin>[/XML]