Weil Sie sie von der Quelle wiederherstellen können. Wenn Sie über JAR-Dateien von Drittanbietern sprechen, die von Ihrem Projekt benötigt werden, ist es ratsam, sie in das Repository zu übertragen, damit das Projekt in sich abgeschlossen ist.
Sie haben also ein Projekt, das einige externe Abhängigkeiten verwendet. Diese Abhängigkeiten sind bekannt. Sie alle haben
In der Maven-Terminologie werden diese Informationen als Artefakt (Ihr Jar) Koordinaten bezeichnet.
Die Abhängigkeiten, über die ich gesprochen habe, sind entweder interne (für eine Web-Anwendung kann es Ihre Service / Domain-Schicht sein) oder extern (log4j, jdbc-Treiber, Java EE-Framework, Sie nennen es, ...). All diese Abhängigkeiten (auch Artefakte genannt) sind tatsächlich auf der untersten Ebene Binärdateien (JAR / WAR / EAR), die Ihr CVS / SVN / GIT nicht effizient speichern kann. In der Tat, SCM verwenden die Hypothese, dass versionierte Inhalte, für die Diff-Operationen am effizientesten sind, nur Text sind. Dies hat zur Folge, dass bei der Speicherung von Binärdaten selten eine Speicheroptimierung stattfindet (im Gegensatz zum Text, bei dem nur Versionsunterschiede gespeichert werden).
Als Konsequenz würde ich Ihnen eher empfehlen, ein Abhängigkeitsverwaltungs-Build-System zu verwenden, wie maven , Ivy oder Gradle . Mit einem solchen Tool deklarieren Sie alle Abhängigkeiten (in dieser Datei deklarieren Sie die Artefaktkoordinaten Ihrer Abhängigkeiten) in einer Textdatei (oder XML-Datei), die sich in Ihrem SCM befindet. ABER Ihre Abhängigkeiten werden nicht in SCM sein. Vielmehr wird jeder Entwickler sie auf seiner Dev-Maschine herunterladen.
Dadurch wird eine gewisse Netzwerklast vom SCM-Server auf das Internet übertragen (die Bandbreite ist oft stärker eingeschränkt als bei einem internen Enterprise-Netzwerk), und es stellt sich die Frage nach der langfristigen Verfügbarkeit von Artefakten. Beide Antworten sind gelöst (zumindest in der amven-Arbeit, aber ich glaube, dass sowohl Ivy als auch Gradle in der Lage sind, sich mit solchen Tools zu verbinden - und es scheint, dass zu diesem Thema einige Fragen gestellt wurden), indem sie Proxies verwenden, wie Nexus , Artefactory und andere.
>Das Schöne an diesen Tools ist, dass sie im internen Netzwerk eine Ansicht aller benötigten Artefakte zur Verfügung stellen, so dass Sie Ihre eigenen Artefakte in diesen Repositories bereitstellen können, wodurch die gemeinsame Nutzung Ihres Codes einfach und unabhängig von der Quelle ist (was ein Vorteil sein kann).
Um diese lange Antwort zusammenzufassen: Verwenden Sie Ivy / Maven / Gradle anstelle von einfachen Ant Build. Mit diesen Tools können Sie Ihre Abhängigkeiten definieren und alle Aufgaben zum Herunterladen dieser Abhängigkeiten ausführen und sicherstellen, dass Sie die deklarierte Version verwenden.
Auf einer persönlichen Notiz, der Tag, an dem ich diese Werkzeuge entdeckte, wurde meine Vision der Abhängigkeitsverarbeitung in Java vom Albtraum zum Himmel, da ich jetzt nur noch sagen muss, dass ich genau diese Version dieses Werkzeugs und Maven (in meinem Fall), tun alle Hintergrund-Job des Herunterladens und Speichern an der richtigen Stelle auf meinem Computer.Quellcodeverwaltungssysteme sind so konzipiert, dass sie den Textquellcode enthalten. Sie können Binärdateien enthalten, aber dafür sind sie nicht wirklich gedacht. In manchen Fällen ist es sinnvoll, eine Binärdatei in die Quellcodeverwaltung zu legen, aber Java-Abhängigkeiten werden in der Regel besser verwaltet.
Die ideale Konfiguration ermöglicht es Ihnen, Ihre Abhängigkeiten außerhalb der Quellcodeverwaltung zu verwalten. Sie sollten Ihre Abhängigkeiten außerhalb der Quelle verwalten und einfach auf die gewünschte Abhängigkeit innerhalb der Quelle "zeigen" können. Dies hat mehrere Vorteile:
Die Dependency Management-Funktionen von Maven lösen diese Probleme für Sie und können Ihnen helfen, Binärabhängigkeiten nach Bedarf zu finden und abzurufen. Ivy ist ein anderes Werkzeug, das dies auch tut, aber für Ant.
Sie sind Binärdateien:
Mit anderen Worten: Verweisen Sie besser auf die Quelle und passen Sie Ihre Build-Skripte an, damit alles funktioniert.
Die Entscheidung, JAR-Dateien an SCM zu übergeben, wird normalerweise vom verwendeten Build-Tool beeinflusst. Wenn Sie Maven auf konventionelle Weise verwenden, haben Sie nicht wirklich die Wahl. Aber wenn Ihr Build-System Ihnen die Wahl erlaubt, denke ich, dass es eine gute Idee ist, Ihre Abhängigkeiten neben dem Quellcode, der von ihnen abhängt, an SCM zu übergeben.
Dies gilt für Drittanbieter-Jars und In-House-Jars, die sich in einem separaten Release-Zyklus zu Ihrem Projekt befinden. Wenn Sie beispielsweise eine interne JAR-Datei mit allgemeinen Dienstprogrammklassen haben, würde ich dies unter jedem Projekt, das es verwendet, an SCM übergeben.
Wenn Sie CVS verwenden, beachten Sie, dass es Binärdateien nicht effizient verarbeitet. Ein SVN-Repository unterscheidet nicht zwischen Binär- und Textdateien.
Update als Antwort auf die Antwort von Mark:
WRT bullet point 1: Ich würde sagen, dass selbst ein großes Projekt nicht sehr häufig Hunderte von Abhängigkeiten hat. In jedem Fall sollte die Festplattennutzung (indem Sie eine separate Kopie einer Abhängigkeit in jedem Projekt, das sie verwendet, beibehalten werden) nicht Ihre Hauptsorge sein. Der Speicherplatz ist billig verglichen mit der Menge an Zeit, die mit der Komplexität eines Maven-Repositories verloren geht. In jedem Fall wird ein lokales Maven-Repository viel mehr Speicherplatz belegen als nur die Abhängigkeiten, die Sie tatsächlich nutzen.
Bullet 3: Maven wird Ihnen nicht die Zeit sparen, die auf Netzwerkverkehr wartet. Das Gegenteil ist wahr. Mit Ihren Abhängigkeiten in der Quellcodeverwaltung führen Sie einen Checkout durch und wechseln dann von einem Zweig zum nächsten. Sie werden sehr selten die gleichen Gläser wieder auschecken müssen. Wenn Sie dies tun, dauert es nur wenige Minuten. Der Hauptgrund, warum Maven ein langsames Build-Tool ist, ist der gesamte Netzwerkzugriff, den es selbst dann tut, wenn es nicht nötig ist.
Bullet Punkt 4: Ihr Argument hier ist kein Argument gegen das Aufbewahren von Gläsern in SCM und Maven ist nur dann einfach, wenn Sie es gelernt haben und es ist nur dann effizient, wenn etwas schief geht. Dann wird es schwierig und Ihre Effizienzgewinne können schnell verschwinden. Hinsichtlich der Effizienz hat Maven ein kleines Plus, wenn die Dinge richtig funktionieren, und einen großen Nachteil, wenn sie nicht funktionieren.
Punkt 5: Versionskontrollsysteme wie SVN bewahren keine separate Kopie jeder Version jeder Datei auf. Es speichert sie effizient als Deltas. Es ist sehr unwahrscheinlich, dass Ihr SVN-Repository zu einer "nicht verwaltbaren" Größe wird.
Bullet Point 6: Ihr Argument hier ist kein Argument gegen das Speichern von Dateien ist SCM. Der von Ihnen erwähnte Anwendungsfall kann genauso einfach mit einem benutzerdefinierten Ant-Build behandelt werden.