marcus/pdf-umbenenner
1
0
Fork 0
Code Issues 14 Releases 2 Activity

Optimierung: Konsistente Versionierung zwischen POM, App-Version und Jenkins-Build #67

New Issue
Closed
opened 2026-04-29 06:53:10 +02:00 by marcus · 1 comment
marcus commented 2026-04-29 06:53:10 +02:00
Owner
Copy Link
Copy Source

Problem

Die Versionierung ist aktuell inkonsistent und manuell:

  • Alle Maven-POMs führen dauerhaft 0.0.1-SNAPSHOT als project.version
  • Die sichtbare Anwendungsversion (2.5.0) ist manuell hardcoded in pdf-umbenenner-packaging/pom.xml als app.version
  • Jenkins erhöht die Build-Nummer automatisch, aber die semantische Versionsnummer (z. B. 3.0.0) muss manuell vom Entwickler angepasst werden
  • Die Anwendungsversion ist in der GUI noch nicht sichtbar (→ Issue #50)

Ziel

Eine saubere, wartungsarme Lösung, bei der:

  1. Die semantische Versionsnummer (z. B. 3.0.0) einmal gepflegt wird
  2. MSI-Installer, MANIFEST.MF und Statuszeile dieselbe Versionsnummer zeigen
  3. Jenkins die Buildnummer automatisch anhängen kann (z. B. 3.0.0.42)

Optionen (zur Entscheidung)

Option Beschreibung Aufwand
Maven CI-friendly Versioning ${revision} als Property im Parent-POM; Jenkins übergibt -Drevision=3.0.0 Gering
Maven Versions Plugin mvn versions:set -DnewVersion=3.0.0 als Jenkins-Step vor dem Build Gering
Beide kombiniert Revision-Property + Jenkins-Build-Nummer als Qualifier Mittel

Empfehlung: Maven CI-friendly Versioning (${revision}) – minimaler Eingriff, kein Plugin-Overhead.

Auswirkungen

  • pdf-umbenenner-packaging: app.version kann durch ${revision} ersetzt werden
  • MANIFEST.MF im Shade-JAR: Implementation-Version automatisch befüllen → Statuszeile kann Version via getClass().getPackage().getImplementationVersion() auslesen
  • pdf-umbenenner-bootstrap: Startlog kann korrekte Version ausgeben

Abhängigkeiten

  • Issue #50 (Statuszeile) – zeigt die Version an
  • Issue #65 (MSI-Installer) – Baustelle "App-Version hardcoded"
  • Issue #67 (Jenkins-Build-Optimierung) – Jenkins-seitige Umsetzung
## Problem Die Versionierung ist aktuell inkonsistent und manuell: - Alle Maven-POMs führen dauerhaft `0.0.1-SNAPSHOT` als `project.version` - Die sichtbare Anwendungsversion (`2.5.0`) ist **manuell hardcoded** in `pdf-umbenenner-packaging/pom.xml` als `app.version` - Jenkins erhöht die Build-Nummer automatisch, aber die semantische Versionsnummer (z. B. `3.0.0`) muss **manuell** vom Entwickler angepasst werden - Die Anwendungsversion ist in der GUI noch nicht sichtbar (→ Issue #50) ## Ziel Eine saubere, wartungsarme Lösung, bei der: 1. Die semantische Versionsnummer (z. B. `3.0.0`) **einmal** gepflegt wird 2. MSI-Installer, MANIFEST.MF und Statuszeile **dieselbe** Versionsnummer zeigen 3. Jenkins die Buildnummer automatisch anhängen kann (z. B. `3.0.0.42`) ## Optionen (zur Entscheidung) | Option | Beschreibung | Aufwand | |---|---|---| | **Maven CI-friendly Versioning** | `${revision}` als Property im Parent-POM; Jenkins übergibt `-Drevision=3.0.0` | Gering | | **Maven Versions Plugin** | `mvn versions:set -DnewVersion=3.0.0` als Jenkins-Step vor dem Build | Gering | | **Beide kombiniert** | Revision-Property + Jenkins-Build-Nummer als Qualifier | Mittel | Empfehlung: **Maven CI-friendly Versioning** (`${revision}`) – minimaler Eingriff, kein Plugin-Overhead. ## Auswirkungen - `pdf-umbenenner-packaging`: `app.version` kann durch `${revision}` ersetzt werden - MANIFEST.MF im Shade-JAR: `Implementation-Version` automatisch befüllen → Statuszeile kann Version via `getClass().getPackage().getImplementationVersion()` auslesen - `pdf-umbenenner-bootstrap`: Startlog kann korrekte Version ausgeben ## Abhängigkeiten - Issue #50 (Statuszeile) – zeigt die Version an - Issue #65 (MSI-Installer) – Baustelle "App-Version hardcoded" - Issue #67 (Jenkins-Build-Optimierung) – Jenkins-seitige Umsetzung
marcus commented 2026-04-30 14:46:07 +02:00
Author
Owner
Copy Link
Copy Source

Umgesetzt in V3.0: Maven CI-friendly Versioning mit ${revision} eingeführt, flatten-maven-plugin konfiguriert (resolveCiFriendliesOnly + flatten.clean), MANIFEST.MF trägt Implementation-Version, Fallback "dev" implementiert, app.version im Packaging-Modul auf ${revision} umgestellt. Build grün, Commit c6379c0.

Umgesetzt in V3.0: Maven CI-friendly Versioning mit ${revision} eingeführt, flatten-maven-plugin konfiguriert (resolveCiFriendliesOnly + flatten.clean), MANIFEST.MF trägt Implementation-Version, Fallback "dev" implementiert, app.version im Packaging-Modul auf ${revision} umgestellt. Build grün, Commit c6379c0.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
No items
No Label
Milestone
No items
No Milestone
Assignees
Clear assignees
marcus
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: marcus/pdf-umbenenner#67
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?