Hallo zusammen,
Wir haben ein Maven Projekt das in einem Subversion Repository eingecheckt ist. In diesem Projekt befinden sich diverse Klassen die sich hin und wieder mal ändern.
Ich möchte nun gerne eine Art Versionsnummer der Klasse automatisch generieren. Da Subversion ja pro Klasse/Datei eine Versionsnummer vorhält, würde diese ja schon ausreichen. Dafür habe ich mir gedacht ähnlich wie bei dem Resource-Filtering vorzugehen, nur halt mit einem eigenen Plugin.
Wenn ich nun in der entsprechenden Klasse eine Variable wie folgt zuweise:
könnte ich doch sicherlich VOR dem compilieren, rekusiv durch meine *.java Files scannen und dort {CLASS.VERSION} ersetzen, oder? Natürlich müsste ich dann auch einen SVN Client bauen der die Versionsnummer ausliest für die entsprechende Klasse.
Meine Alternative wäre halt ein Hashwert für die Klasse. Es wäre zwar schön zu wissen in welcher Version sich die Klasse zur Laufzeit befindet, aber ein Hash würde auch reichen.
Hintergrund (falls es interessiert):
Wir entwickeln mit mehreren Entwicklern an diesem Projekt. In dem Projekt sind verschiedene Schnittstellen zu unseren Kunden. Wenn ein Kunde ein Update bekommt, bekommt er automatisch die aktuelle Version von allen Schnittstellen.
Nun möchte ich gerne wissen, wenn zB eine Datei eingelesen wird durch eine Schnittstelle, mit welcher Schnittstellen-Version diese Datei genau eingelesen wurde.
Die Projekt-Versionsnummer kann ich bereits durch das Resource-Filtering auslesen. Wenn der Kunde aber nun ein Problem hat mit der Schnittstelle, könnte ich zwar sehen das seit dem Problem eine neue Projekt-Versionsnummer läuft, aber evt hat sich an der entsprechenden Schnittstellen-Klasse nichts geändert.
Natürlich wäre die einfachste Möglichkeit die Version manuell hoch zu zählen, aber vermutlich kann man sich das dann auch sparen, da wir das dann ständig vergessen würden.
Alternative wäre natürlich jede Schnittstelle in ein eigenes Projekt auszulagern, aber das würde massiven Umbau bedeuten.
Habt Ihr evt eine andere Idee? Denn die Idee mit dem SVN Client und *.java Files durchscannen finde ich selbst auch nicht so richtig schön.
Vielen Dank und ein schönen Sonntag noch,
Hauke
Wir haben ein Maven Projekt das in einem Subversion Repository eingecheckt ist. In diesem Projekt befinden sich diverse Klassen die sich hin und wieder mal ändern.
Ich möchte nun gerne eine Art Versionsnummer der Klasse automatisch generieren. Da Subversion ja pro Klasse/Datei eine Versionsnummer vorhält, würde diese ja schon ausreichen. Dafür habe ich mir gedacht ähnlich wie bei dem Resource-Filtering vorzugehen, nur halt mit einem eigenen Plugin.
Wenn ich nun in der entsprechenden Klasse eine Variable wie folgt zuweise:
Java:
private final String VERSION = "{CLASS.VERSION}";könnte ich doch sicherlich VOR dem compilieren, rekusiv durch meine *.java Files scannen und dort {CLASS.VERSION} ersetzen, oder? Natürlich müsste ich dann auch einen SVN Client bauen der die Versionsnummer ausliest für die entsprechende Klasse.
Meine Alternative wäre halt ein Hashwert für die Klasse. Es wäre zwar schön zu wissen in welcher Version sich die Klasse zur Laufzeit befindet, aber ein Hash würde auch reichen.
Hintergrund (falls es interessiert):
Wir entwickeln mit mehreren Entwicklern an diesem Projekt. In dem Projekt sind verschiedene Schnittstellen zu unseren Kunden. Wenn ein Kunde ein Update bekommt, bekommt er automatisch die aktuelle Version von allen Schnittstellen.
Nun möchte ich gerne wissen, wenn zB eine Datei eingelesen wird durch eine Schnittstelle, mit welcher Schnittstellen-Version diese Datei genau eingelesen wurde.
Die Projekt-Versionsnummer kann ich bereits durch das Resource-Filtering auslesen. Wenn der Kunde aber nun ein Problem hat mit der Schnittstelle, könnte ich zwar sehen das seit dem Problem eine neue Projekt-Versionsnummer läuft, aber evt hat sich an der entsprechenden Schnittstellen-Klasse nichts geändert.
Natürlich wäre die einfachste Möglichkeit die Version manuell hoch zu zählen, aber vermutlich kann man sich das dann auch sparen, da wir das dann ständig vergessen würden.
Alternative wäre natürlich jede Schnittstelle in ein eigenes Projekt auszulagern, aber das würde massiven Umbau bedeuten.
Habt Ihr evt eine andere Idee? Denn die Idee mit dem SVN Client und *.java Files durchscannen finde ich selbst auch nicht so richtig schön.
Vielen Dank und ein schönen Sonntag noch,
Hauke
