Versionscode aus build.gradle in Java-Klasse ausgeben lassen

[_user_q]

In der build.gradle-Datei habe ich fürs Beispiel folgende Version angegeben:

version '0.1.0'

Diesen Versionscode möchte ich jetzt woanders ausgeben lassen. Ich habe bereits so was wie

getClass().getPackage().getImplementationVersion()

ausprobiert, aber das ist null. Im Internet wurde ich nicht wirklich fündig ...

Danke.

 

[KonradN]

Erst einmal ist die Version nur in Gradle. Die Version gibt es so innerhalb der Java Laufzeitumgebung nicht.

Somit müsstest Du im Rahmen des Build Prozesses diese Version dem Programm bereit stellen.

Ideen diesbezüglich findest Du z.B. unter:

How to get version attribute from a gradle build to be included in runtime Swing application

I have a simple parent project with modules/applications within it. My build tool of choice is gradle. The parent build.gradle is defined below. apply plugin: 'groovy' dependencies { compile

stackoverflow.com

 

[_user_q]

Erst einmal ist die Version nur in Gradle. Die Version gibt es so innerhalb der Java Laufzeitumgebung nicht.

Somit müsstest Du im Rahmen des Build Prozesses diese Version dem Programm bereit stellen.

Ideen diesbezüglich findest Du z.B. unter:

How to get version attribute from a gradle build to be included in runtime Swing application

I have a simple parent project with modules/applications within it. My build tool of choice is gradle. The parent build.gradle is defined below. apply plugin: 'groovy' dependencies { compile

stackoverflow.com

Hm, okay. Dann ist es wohl besser, ein String mit dem Versionscode in die Main-Klasse zu schreiben, da die manuelle Veränderung da drauf - würde ich jetzt mal behaupten - am geringsten ist, denn den Inhalt einer Properties-Datei kann man ggf. verändern. 🤔

public (static)? final String programVersion = "0.1.0";

Aber ich habe diese Art (meine jetzige Idee) auch schon mal woanders gesehen.

 

[KonradN]

In dem Stackoverflow-Beitrag sind ja auch Möglichkeit genannt. Was hier also üblich ist (Ich kenne es aus dem Maven Umfeld), dass man beim Build dies ein eine Datei schreiben lässt um dann diese Datei zur Laufzeit auszuwerten. Das ist nicht wirklich komplex.

Auch der erste Ansatz, den Du versucht hast, geht ja schon in diese Richtung (Und der Weg ist ja auch erwähnt - derzeit an zweiter Stelle). Da ist aber die Beschränkung, dass dies halt nur aus dem generierten jar funktioniert - so die Informationen im Manifest hinterlegt wurden. In der Entwicklungsumgebung hast du noch kein Manifest - die IDE erzeugt das halt nicht für einen einfachen Start.

Ich selbst bevorzuge in der Regel den Weg über Ressourcen - da ich erfahrungsgemäß auch noch andere Informationen mit auslesen möchte zur Laufzeit.

 

[_user_q]

In dem Stackoverflow-Beitrag sind ja auch Möglichkeit genannt. Was hier also üblich ist (Ich kenne es aus dem Maven Umfeld), dass man beim Build dies ein eine Datei schreiben lässt um dann diese Datei zur Laufzeit auszuwerten. Das ist nicht wirklich komplex.

Auch der erste Ansatz, den Du versucht hast, geht ja schon in diese Richtung (Und der Weg ist ja auch erwähnt - derzeit an zweiter Stelle). Da ist aber die Beschränkung, dass dies halt nur aus dem generierten jar funktioniert - so die Informationen im Manifest hinterlegt wurden. In der Entwicklungsumgebung hast du noch kein Manifest - die IDE erzeugt das halt nicht für einen einfachen Start.

Ich selbst bevorzuge in der Regel den Weg über Ressourcen - da ich erfahrungsgemäß auch noch andere Informationen mit auslesen möchte zur Laufzeit.

Wenn ich das Programm jedoch - ich sag mal - als Executable Jar exportiere und diese Jar-Datei dann ausführe, dann gibt es ja keinen build-Ordner mehr. 🤔

 

[KonradN]

Wenn ich das Programm jedoch - ich sag mal - als Executable Jar exportiere und diese Jar-Datei dann ausführe, dann gibt es ja keinen build-Ordner mehr. 🤔

Die Datei erzeugst Du im resources Ordner (Also was standardmäßig src/main/resources wäre). Damit landet die Datei auch im jar und kann problemlos als Ressource gelesen werden.

 

[_user_q]

Die Datei erzeugst Du im resources Ordner (Also was standardmäßig src/main/resources wäre). Damit landet die Datei auch im jar und kann problemlos als Ressource gelesen werden.

Soll diese Datei in dem Ordner beim Beenden wieder gelöscht werden oder einfach dort verbleiben, bis sie, wenn es eine neue Version gibt, verändert wird?

 

[KonradN]

Soll diese Datei in dem Ordner beim Beenden wieder gelöscht werden oder einfach dort verbleiben, bis sie, wenn es eine neue Version gibt, verändert wird?

Die Datei würde ich nicht in die Sourcecode-Verwaltung aufnehmen, aber ich würde mir nicht die Arbeit machen, dass diese bei einem Clean gelöscht wird (Wobei das sauberer wäre).

 

[_user_q]

Die Datei würde ich nicht in die Sourcecode-Verwaltung aufnehmen, aber ich würde mir nicht die Arbeit machen, dass diese bei einem Clean gelöscht wird (Wobei das sauberer wäre).

Aber das verbraucht doch auf lange Zeit gesehen viel mehr Rechenleistung, als wenn man die Version in einen String speichert oder wieso der Umstand?
Hat Sourcecode-Verwaltung etwas mit Revision zu tun oder was ist das?

 

[mrBrown]

Aber das verbraucht doch auf lange Zeit gesehen viel mehr Rechenleistung, als wenn man die Version in einen String speichert oder wieso der Umstand?

Beim Build einen String in einer Datei speichern und diesen dann zur Laufzeit auslesen verbraucht so wenig Rechenzeit, dass man es wahrscheinlich nicht mal messen kann - das geht in den duzenden bis hunderten anderen Dateien unter, die dabei jede Mal gelesen werden.

Vermutlich würde das ändern per Hand sogar mehr Energie kosten, der Rechner läuft dafür immerhin ein paar Sekunden länger.

 

[_user_q]

Beim Build einen String in einer Datei speichern und diesen dann zur Laufzeit auslesen verbraucht so wenig Rechenzeit, dass man es wahrscheinlich nicht mal messen kann - das geht in den duzenden bis hunderten anderen Dateien unter, die dabei jede Mal gelesen werden.

Vermutlich würde das ändern per Hand sogar mehr Energie kosten, der Rechner läuft dafür immerhin ein paar Sekunden länger.

Warum wird das denn überhaupt in eine Datei geschrieben? Auch wenn ich das jetzt einfach mit 'nem String machen würde, verstehe ich das noch nicht so ganz. Die Datei muss ja erstellt und beim Beenden vielleicht wieder gelöscht werden. Bei einer Versionsänderung muss ein neuer String in die Datei geschrieben werden und diesen String würde man auch aus der Datei auslesen (oder nicht?) - so wie ich das jetzt verstanden habe. Warum der ganze Umstand?

 

[KonradN]

Die Datei muss ja erstellt und beim Beenden vielleicht wieder gelöscht werden.

Was meinst Du beim Beenden? Es geht doch um den Build Prozess und nicht um den Ablauf bei Programmstart.

Der Build Prozess verarbeitet die Projektdateien:

• Die Projekt Konfiguration (Bei Dir die Gradle Dateien)
• Die Source Dateien (Die werden übersetzt)
• Die Resource Dateien (Die werden kopiert)
• Die Ergebnisse werden dann ggf. weiter verarbeitet: Evtl. werden Abhängigkeiten kopiert, jar Dateien erzeugt, per JLink und JPackage Images / Installer erstellt ....

(Ist etwas vereinfacht / grob dargestellt. Es kann auch Code erzeugt werden u.s.w.)

Und im Rahmen dieses Prozesses wird dann auch eine Ressource Datei erzeugt. So wie auch viele .class Dateien erzeugt werden. Und das landet dann ggf. in alles in einem jar / images / was auch immer.
==> Da wird also nichts gelöscht!

Wenn Du in einem Projekt ein "clean" startest, dann sollte alles, was generiert wurde, auch gelöscht werden. Daher wäre die Frage, wo denn generierte Ressourcen in Gradle hin gehören. Du könntest diese Resource Datei auch direkt im entsprechenden Zielverzeichnis generieren. Das wäre recht sauber, denn das wird beim clean gelöscht.
ABER: Dann hast Du ggf. wieder das Problem, dass die IDE irgend welche Sonderlocken macht und dann versucht, den Code ohne diese Datei zu starten. (Muss man ggf. ausprobieren!)

Ich möchte da keine Wertung machen. Ich habe bei meinen Testprojekten zu Spring Boot mit Angular es so gemacht, dass die Angular App direkt im Resource Folder erzeugt wird. (Ich habe diese dann sogar eingecheckt - das ist aber eher schlecht.) Ich muss gestehen, dass ich es nicht so tief durchdacht hatte und da eher Anderen "blind" gefolgt bin. Da kann man drüber diskutieren, aber da sind wir jenseits der Funktionalität sondern rein bei einer Clean Project Diskussion. (Und der Ansatz war so halt leichter nachzuvollziehen: Man sieht nach dem ng Aufruf die Dateien in dem resource Folder und die folgenden Schritte sind dann nichts besonderes mehr. Und es gibt ja auch so Dinge wie "hot deploy" - eine Veränderung in der IDE schiebt in den laufenden Prozess (den man gerade Testet / Debugt) die Änderungen rein.)

Aber in Maven sieht das auch etwas anders aus. Da schreibt man eine Properties Datei mit Platzhaltern und im Maven hat man ein Plugin, dass diese Platzhalter dann austauscht. Damit hat man einen sauberen Stand und das Plugin kümmert sich um die Anpassung. Das aber nur ein kleiner Hinweis am Rande.

 

[mrBrown]

Warum wird das denn überhaupt in eine Datei geschrieben?

Irgendwo muss die Version ja stehen, wenn du die zur Laufzeit brauchst - und da gibt’s nur zwei Möglichkeiten: direkt im Code oder in irgendeiner Datei die du dann ausliest.

Du kannst auch selbst einfach mal pro und kontro-Punkte für beides sammeln, vielleicht sind dir ja auch völlig andere Dinge wichtig als uns.

 

[Jw456]

Warum wird das denn überhaupt in eine Datei geschrieben?

Bei Android zb erkennt Google ob das was du neu hoch lädst auch eine neue Version ist. Es akzeptiert eigentlich nur Uploads mit größer als die alte Version.

 

[Neumi5694]

Die Version meiner Releases kenn ich gar nicht, über die ausgegebene Versionsnummer entscheidet jemand anderes. Während des Build-Prozesses wird sie in's Manifest der Jar-Datei geschrieben (zum Auslesen und Anzeigen), außerdem wird sie verwendet, um die Versionsnummer der kompilierten .exe Datei zu setzen. Eine brauchbate Alternative - sofern man immer über einen Launcher startet - wäre, die Versionsnummer nicht im Manifest zu hinterlegen, sondern als System Property vom Launcher zu empfangen.