# Jar-Datei Versionen



## fastjack (26. Jan 2010)

Hallo,

sorry für das lange Posting. Ich wollte fragen, ob es eine gängige Praxis gibt, wie man Jar-Dateien versioniert. Das man sie im SVN pflegen kann, weis ich auch. Wie siehts aber beispielsweise mit der Benamung aus? Ich mache mal ein fiktives Beispiel: Es gibt ein Projekt A, dazu die a.jar Datei. Das Projekt soll sich in der fiktiven Version 5.8 befinden. 
Andere Projekte, z.B. B, C und D benötigen die a.jar Datei. Die Projekte A, B, C werden vom selben Entwicklungsteam entwickelt, teilweise auch paralell, eine neue Version von A ist im Normalfall unkritisch (verteilt durch Dateikopie, SVN etc.). Jeder Entwickler dieses Teams kann A, B, C bei sich bauen und verwalten. D allerdings muß von einem externen Entwicklungsteam aufwendig deployt und getestet werden, hier wird die a.jar beispielsweise durch Mail verteilt etc.

Man erkennt also schon mal interne (A, B, C) und externe Entwickleransichten (D).

Dazu gesellen sich Test/Produktivumgebungen von A, B, C und natürlich extern D. Insbesondere bei den Produktivumgebungen sollen Supporter kurz und knackig Antwort geben können, welche Versionen von A in B, C, D genutzt werden.

Eine Lösung und Praxis: Die a.jar Datei könnte im Dateinamen um die Versionsangabe und/oder im Manifest ergänzt werden. Beides hat Vor- und Nachteile. Sind Versionsnummern im Dateinamen, benötigt man spezielle Update/Deployverfahren, im Gegensatz zum einfachen Kopieren. Allerdings läßt sich die Version relativ leicht ablesen und nicht erst durch Öffnen der Jar.

Meines Erachtens gibt es unterschiedliche Belange (Entwicklung-Intern, Extern, Produktiv etc.) und Arten der Lösung. Was haltet Ihr davon und vor allem wie wird es bei Euch in den Firmen gemacht ? Gibt es eine "Thats It!" Lösung ? 

Danke für Euer Braining und bis denne


----------



## maki (26. Jan 2010)

Was du willst schaffst du mit Dependency Management, das ist mehr als nur irgendwelche Jars/Libs/artifakte in ein Quellcode Repository zu werfen, Maven2 kann das, Buckminster auch für Eclipse RCP Projekte.


----------



## Wildcard (26. Jan 2010)

Ausserdem würde ich ein klares Versionsschema einführen. Ich würde dabei die OSGi Versionsnummern verwenden, das ist eine gängige Praxis für alles Modul-basierte.
Solltet ihr dann irgendwann mal einen Umstieg auf OSGi in Betracht ziehen, lassen sich damit auch klare Version Constraints (Ranges) der Abhängigkeiten definieren.
Wenn euer Build nicht Maven basiert ist (danach hört es sich ja an) würde ich mir Buckminster oder Ivy anschauen. Mit beiden ist es möglich Dependencies in der Richtigen Version aufgrund eines Namens Patterns automatisiert herunterzuladen. Wenn ihr euch entscheidet die Versionsnummer nicht an die Jar anzuhängen, dann eher Buckminster, da man sich mit Buckminster die Versionsinformation auch aus Metainformationen ziehen kann.
Wenn es Buckminster werden soll, dann können die Kunden/Entwickler auch direkt eine BOM erzeugen lassen in der dann exakt steht welche Versionen von welcher Abhängigkeit lokal verwendet werden.


----------



## fastjack (27. Jan 2010)

Vielen Dank für Eure Tips


----------

