Umgebungsvariable Version des Programms

[Maaanuel]

Hallo,
via den button "über" kann man in meiner Applikation allgemeine Infos abfragen (wie man es von den meisten Programmen kennt). So z.B. auch die Versions-Nummer der Applikation.

Nun ist nur meine Überlegung, wo speichert man intern im Code am besten die aktuelle Versions-Nummer?
Hat mein eine Art "Settings.java" in der man die wichtigsten Einstellungen per Konstanten machen kann und dort ist auch die Versionsnummer?

Ich weiß, eigentlich ein sehr unwichtiges Thema aber ich interessiere mich dafür, wie schöner Code ist und wie man es normalerweise macht.


Über Google kam ich leider zu nichts, da bei java + version (egal welcher zusatz, wie programmieren, code) nur Infos herauskommen, wie man die aktuelle Version von Java an sich herausfinden kann.

Danke für eure Meinungen.

 

[Flown]

Also wenn ich soetwas mache, dann würde ich soetwas in einem Propertyfile auslagern.

 

[Gonzo17]

Also wenn ich soetwas mache, dann würde ich soetwas in einem Propertyfile auslagern.

Hätte ich jetzt reflexartig auch zuerst gesagt, aber ich stelle mir gerade ernsthaft die Frage: warum? Welchen Vorteil hätte man davon? Wieso nicht in einer Klasse?

Mir würde als Argument nur einfallen, dass man dann die Version seiner Software per Hand pflegen muss und nicht automatisiert vergeben lassen kann. (Sowas macht übrigens ein Build-Tool wie Maven schon automatisch) Aber sonst?

 

[Maaanuel]

ok, ich hätte spontan gesagt, nicht in eine externe-File wie in einer Propertyfile.
Diese liegen ja in der jar im Klartext, können also einfach geändert werden. Auch wenn dies keine wirklich schlimmen Auswirkungen haben würde hätte ich gesagt, dass dies fest im Code sein sollte, damit es (weitgehend) unveränderlich ist.

 

[maki]

Property Dateien sind IMHO der richtige Ort dafür, gibt auch Alternativen, im Code selber ist die schlechteste Option IMHO, da man hierfür soz. den Quellcode "filtern" müsste, was man eigtenlich nur mit reinen Textressourcen wie zB. Property oder XML Dateien macht.

 

[Gonzo17]

im Code selber ist die schlechteste Option IMHO, da man hierfür soz. den Quellcode "filtern" müsste, was man eigtenlich nur mit reinen Textressourcen wie zB. Property oder XML Dateien macht.

"Filter"? Verstehe nicht, was du da genau meinst. Wenn die Version einfach als String hinterlegt wird oder evtl als int, wo wäre das Problem?

 

[maki]

"Filter"? Verstehe nicht, was du da genau meinst. Wenn die Version einfach als String hinterlegt wird oder evtl als int, wo wäre das Problem?

Wenn das automatisiert gemacht wird, wird meist vom Buildsystem (Ant, maven, etc. ) "gefiltert", d.h. dass Platzhalter zB. in der Form [c]${project.version}[/c] durch echte Werte wie [c]1.0.1[/c] ersetzt würden.

Das geht natürlich auch in Java Dateien und nicht nur in Property/XML Dateien, meist ist es aber praktischer nur 2-4 XML/Property Dateien zu filtern als hunderte Java Dateien und man hat alles gefilterte an einer bzw. an wenigen Stellen.

Da man meist mehr als nur die Version ersetzen will (DB URLs, JDBC Treiber, Nutzernamen & Passwort, etc. pp.) und solche Dinge sowieso schon gefiltert würden bietet es sich eben an.

 

[Gonzo17]

Wenn das automatisiert gemacht wird, wird meist vom Buildsystem (Ant, maven, etc. ) "gefiltert", d.h. dass Platzhalter zB. in der Form [c]${project.version}[/c] durch echte Werte wie [c]1.0.1[/c] ersetzt würden.

Das geht natürlich auch in Java Dateien und nicht nur in Property/XML Dateien, meist ist es aber praktischer nur 2-4 XML/Property Dateien zu filtern als hunderte Java Dateien und man hat alles gefilterte an einer bzw. an wenigen Stellen.

Achso, klar ich verstehe. Ich bin jetzt davon ausgegangen, dass man es manuell setzen würde, wenn man es im Code beerdigt. Wenn man es automatisiert möchte, dann würde ich wie oben gesagt auch davon abraten das im Code festzuhalten. Aber die Frage ist eben, ob man das automatisiert machen kann/will/soll und wie die Version aussehen soll.

 

[maki]

Wenn man es manuell macht, dann muss man wissen wohin man greift 😉
Wenn es nur eine einzige Stelle im Code ist (zB. eine Klasse für alle Einstellungen), wäre das ok.
Ab 2 Stellen wäre mir das zu unsicher... ist aber Geschmackssache.

 

[Swoop]

Wenn man es manuell macht, dann muss man wissen wohin man greift 😉
Wenn es nur eine einzige Stelle im Code ist (zB. eine Klasse für alle Einstellungen), wäre das ok.
Ab 2 Stellen wäre mir das zu unsicher... ist aber Geschmackssache.

Eine Klasse mit statischen Variablen mach ich in kleinen Programmen immer ... und von dort aus wird die Versionsnr immer verwendet!

 

[Gast2]

Also ich mach das über Werte im manifest, welche vom Build scripts dort reingeschrieben werden.
Auf diese Art kann man aohne Probleme SVN Revision etc mit einkompilieren.

String VERSION = getAttributeFromManifest("PROGRAMMNAME-Version");

private static String getAttributeFromManifest(String attributeName) {
		String attributeValue = null;
		if (!(attributeName == null)) {
			try {
				Enumeration<URL> resources = CLASSNAME.class.getClassLoader()
						.getResources("META-INF/MANIFEST.MF");
				while (resources.hasMoreElements()) {
					Manifest manifest = new Manifest(resources.nextElement()
							.openStream());
					Attributes attr = manifest.getMainAttributes();
					String mainClass = attr.getValue("Main-Class");
					if (mainClass != null
							&& mainClass
									.equals("package.CLASSNAME")) {
						attributeValue = attr.getValue(attributeName);
					}
				}
			} catch (Exception E) {
				// nothing irrelevant
			}
		}
		if (attributeValue == null) {
			attributeValue = "undeterminable";
		}
		return attributeValue;
	}

		<!-- Create the subversion version string -->
		<exec executable="svnversion" failifexecutionfails="no" outputproperty="svn.version">
		  <arg value="PATH_TO_REPO"/> 
		  <arg value="-n"/>
		</exec>
		
		<!-- create programs jar archive -->
		<jar destfile="${dist.directory}/PROGRAMMNAME.jar">
			<manifest>
			    <attribute name="Svn-Revision"  value="${svn.version}" /> 
			    <attribute name="PROGRAMMNAME-Version"  value="${dist.version}" /> 
...
..
.