Hallo
Ich würde gern im namen der jar die Version bei jedem “compile” von maven automatisch erhöhen.
Dazu fand ich gefühlt eine million wege doch keiner hat bei mir funktioniert. Wahrscheinlich weil ich noch nicht so sicher im umgang mit maven bin.
Ich nutze Eclipse Luna und das Maven Plugin für eclipse.
Wenn jemand eine einfache möglichkeit kennt, bitte hier posten.
lg
Zicky
Ich würde ja Behaupten, dass “package” der richtige Trigger wäre…
“Compile” läuft nämlich in Eclipse gar nicht, wenn Du’s nicht explizit aufrufst. Und “compile” liefert auch keine Jars…
bye
TT
mit package wäre ich auch zufrieden. wie geht das ?
mvn package
Aber Spass bei seite: welche methoden hast Du denn schon ausprobiert?
Wir erzeugen mit dem Groovy-Plugin eine Build-nummer, die dann Bestandteil des Artefaktnamens wird. Letzteres erledigt das maven-jar-plugin
[XML]
org.apache.maven.plugins
maven-jar-plugin
2.3.2
${artefactId}-${YOUR_VERSION_VARIABLE_NAME}
[/XML]
bye
TT
Die jar version sollte der source version entsprechen inkl. Tag, sonst ist das sinnfrei.
Das erreicht man zB. einem release, package reicht nicht.
bist du sicher, dass du tatsächlich die Version des Artifacts bei jedem compile-Vorgang erhöhen willst? Oder meinst du so etwas wie eine Build-Nummer? Für letzteres gibt es das buildnumber-maven-plugin
Hi,
die Lösung per finalName tag funktioniert nur im target folder aber nicht wenn ich dann ein mvn deploy mache…
Weiterhin wäre die Frage was spricht gegen SNAPSHOT’s ? Weiterhin kann man mithilfe von versions-maven-plugin und maven-release-plugin die entsprechende Incrementierung im Rahmen einer Release automatisieren?
Und da fällt mir noch ein:
Man könnte auch mal Maven 3.2.X nehmen und die Version dann mit entsprechenden Platzhaltern zu versehen…
Auszug aus den Release Notes:
A simple change to prevent Maven from emitting warnings about versions with property expressions. Allowed property expressions in versions include ${revision}, ${changelist}, and ${sha1}. These properties can be set externally, but eventually a mechanism will be created in Maven where these properties can be injected in a standard way. For example you may want to glean the current Git revision and inject that value into ${sha1}. This is by no means a complete solution for continuous delivery but is a step in the right direction.
Somit steht dann sowas nichts mehr im Wege:
[XML] com.soebes.examples.j2ee
parent
1.0.4-${revision}-SNAPSHOT
pom
[/XML]
Das kann man dann sogar vollständig anpassen…
[XML] com.soebes.examples.j2ee
parent
${revision}-${sha1}${changeset}
pom
[/XML]
Das führt aber dazu, dass man eben immer entsprechende Daten immer über die Kommandozeile angeben muss:
mvn -Drevision=1.2.3 -Dsha1=GITXX -Dchangeset="-SNASPHOT"
Was nicht unbedingt immer ein Nachteil ist…kann man ja per CI Tools entsprechende durchführen lassen…
Gruß
Karl Heinz Marbaise
Ich finde bei solchen Ideen sollte man sich immer prüfen, warum das genutzte Tool (hier Maven) dies nicht von sich aus zur Verfügung stellt. Häufig kommt dann dabei heraus, dass es anders eventuell sinnvoller ist.
ohne genaue Kenntnisse, mit Vermutungen zum Vorgang:
das Tool, welches die Kompilierung anstößt, durchführt, physikalisch das Jar erzeugt, soll nicht dafür sorgen welche Nummer das Jar bekommt?
ob wirklich ‚Version‘ gemeint ist, falls das ein Fachbegriff sein sollte im Gegensatz zu ‚Build-Nummer‘ usw., kling ja nicht ganz felsenfest wissend in der Frage,
vielleicht genau ‚Build-Nummer‘ passend
und wenn, wär es dann nicht praktisch auch die Alternative zu nennen, die Richtung aufzuzeigen? soll es z.B. die IDE machen? (beliebig irgendwas anderes genannt)
oder wenigstens sagen wenn man sie nicht weiß, dann keine Nachfrage/ Zweifel ob das Offensichtliche/ Ungenannte übersehen nötig 
bei Dingen wie Maven mit unendlich Möglichkeiten ist doch die Masse überfordert,
und es gibt evtl. keine Doku die auf einen Blick klären kann was richtig und falsch ist, ‚Version‘ ist ja vielleicht nichmal definiert
(allerdings sehe ich den version-Tag, wie gesagt ohne Kenntnisse Blick von außen )
Allowed property expressions in versions include ${revision}, ${changelist}, and ${sha1}. These properties can be set externally, but eventually a mechanism will be created in Maven where these properties can be injected in a standard way. […] This is by no means a complete solution for continuous delivery but is a step in the right direction.
klingt ja nach einem Volltreffer zu einer derartigen Suche, aber auch nach allem anderen als eindeutiger Sachlage bei Maven dazu…
Hi,
sorry habe wohl heute ein Brett vor dem Kopf…den folgenden Satz verstehe ich schlicht nicht?
Danke.
Karl Heinz Marbaise
(weiterhin unter Rücksicht dass ich keine direkte Ahnung habe)
die Themenfrage ist nach Version-Beeinflussung,
der Hinweis von Sym ist, statt nach die Wie zu fragen besonders erst nachzuschauen, ob das überhaupt möglich und angebracht ist,
und dieser ‚Auszug aus den Release Notes‘ spricht von der Version-Beeinflussung,
außerdem ist herauszulesen dass genaue Mechanismen, vermutlich auch Vorstellungen der Anwender dazu unklar, in der Findung sind
das war für mich ein Volltreffer, sowohl zur Frage an sich als auch zur Anmerkung von Sym
(klingt in der Wiederholung immer blöd betont, so sehr wollte ich dazu gar nicht meckern 
)
Ah…danke für die Ergänzungen.
Aus der Nutzung ergeben. sich bestimmte Konsequenzen…Aus Maven Sicht Released…dann ist das mit dem Aufräumen in SNAPSHOT Repositories nicht mehr ganz so einfach…kann aber über STAGING gelöst werden…Da wird noch einiges passieren…
Gruß
Karl Heinz Marbaise