Java-jar-Dateien in einem repository (CVS, SVN,..)

Warum es eine schlechte Idee, zu Begehen Java-jar-Dateien in einem repository (CVS, SVN,..)

  • Könnten Sie das klären, wenn Sie reden über die Dritte-Partei-Gläser oder Gläser, die generiert werden, von Ihrem eigenen source-code?
  • Beide. jar-Dateien, die generiert werden, aus Quellen, die von uns Besitz-und third-party/open-source-jar-Dateien.
  • Diese können sein diskutiert für immer, meine Vorliebe besteht darin, die Gläser und NICHT die Verwendung eines dependency-engine, wie Sie nur einführen, eine weitere Ebene der Komplexität für ein unglaublich einfaches problem zu verwalten.
  • Was auch immer Sie tun, stellen Sie sicher, dass, wenn jemand, der das Projekt auscheckt, Sie können einfach laufen Ihre build-Skript, und Sie werden alles, was Sie brauchen, egal ob Sie eine Abhängigkeit Motor wie Efeu oder Maven oder nur das verwalten der Bibliotheken selbst.
InformationsquelleAutor Neel | 2011-01-10
  1. 8

    Weil Sie neu erstellen können Sie von der Quelle. Auf der hand, wenn man über Drittanbieter-JAR-Dateien benötigt, die von Ihrem Projekt, dann ist es eine gute Idee, diese zu Begehen, in dem repository, so dass das Projekt eigenständig.

    • Gut, für Abhängigkeiten, die Lösung ist nicht SCM, sondern bei der Verwendung eines dependency-management-tool (wie Efeu oder Maven), um Ihre definition in SCM, aber die effektive Gläser anderswo.
    • dies sollte eine Antwort sein
    • Können Sie beschreiben, warum Sie denken, es ist eine gute Idee, um Shop Gläser an anderer Stelle? Der poster hat wahrscheinlich gesehen, Kommentare wie das Ihre, vor dem Sie dazu aufgefordert werden, ihn zu bitten, seine Frage und seine eine, war mir rätselhaft zu.
    • Machte ich eine Antwort von diesem Kommentar, vielen Dank für Sie Kommentare.
    InformationsquelleAutor Darin Dimitrov
  2. 7

    So, Sie haben ein Projekt, das nutzen einige externe Abhängigkeiten. Diese Abhängigkeiten sind bekannt. Sie alle haben

    • Eine Gruppe (in der Regel die Organisation/forge erstellen Sie Sie)
    • Eine Kennung (Ihr name)
    • Eine version

    In maven-Terminologie werden diese Informationen genannt werden, das Artefakt (Ihre Jar-Koordinaten).

    Die Abhängigkeiten, von denen ich Sprach, sind entweder intern (für eine web-Anwendung, kann es die service - /domain-layer) oder externe (log4j, jdbc-Treiber, die Java-EE-framework, you name it, ...). All diese Abhängigkeiten (auch Artefakte genannt) sind in der Tat, auf dem niedrigsten level, binäre Dateien (JAR/WAR/EAR), die Ihre CVS/SVN/GIT nicht in der Lage, effizient zu speichern. In der Tat, SCM verwenden Sie die Hypothese, dass versionned Inhalte, die man für die diff-Operationen sind die meisten effizient) nur text ist. Als eine Folge wird, wenn binäre Daten gespeichert werden, ist selten storage-Optimierung (im Gegensatz zum text, wo-Versionen nur die Unterschiede gespeichert werden).

    Als Folge, was ich würde dazu neigen, empfehlen Sie, ist die Verwendung eines dependency management build-system, wie maven, Ivy, oder Gradle. mit einem solchen tool, werden Sie erklären, alle Ihre Abhängigkeiten (in der Tat, in dieser Datei, Sie erklären Ihre Abhängigkeiten' Artefakte Koordinaten) in einem text (oder vielleicht XML) Datei, die in Ihrem Schaltplan. ABER Ihre Abhängigkeiten werden nicht in den Schaltplan. Eher, jeder Entwickler wird laden Sie Sie auf Ihren dev-Maschine.

    Dieser überträgt einige Netzwerk-Last aus der SCM-server auf das internet (die Bandbreite ist oft mehr eingeschränkt als interne Enterprise-Netzwerk), und stellt die Frage der langfristigen Verfügbarkeit von Artefakten. Diese beiden Antworten sind gelöst (zumindest in amven Arbeit, aber ich glaube, dass beide Ivy und gradle sind in der Lage, eine Verbindung zu solchen tools - und es scheint, einige Fragen sind gebeten worden, auf dieses Thema) mit Unternehmen proxies, wie Nexus, Artifactory und andere.

    Die Schönheit dieser Werkzeuge ist, dass Sie verfügbar im internen Netzwerk einen Blick alle notwendigen Artefakte, so weit zu gehen, wie es Ihnen ermöglicht die Bereitstellung Ihrer eigenen Artefakte in diesen Repositorys, so dass die Freigabe des Codes einfach und unabhängig von der Quelle (was ein Vorteil sein kann).

    Fazit dieser langen Antwort : verwenden Sie Efeu/Maven/Gradle statt der einfachen Ant build. Diese Werkzeuge erlauben Ihnen, zu definieren, Abhängigkeiten, und alles tun, die Arbeit des Herunterladens von diesen Abhängigkeiten und die Gewährleistung der Verwendung der erklärten version.

    Auf eine persönliche note, der Tag, entdeckte ich jene Werkzeuge, meine vision von dependency-handling in Java bekommen, aus einem Alptraum in den Himmel, als ich jetzt nur zu sagen, dass ich mit dieser version von diesem tool, und maven (in meinem Fall), alles tun, die hintergrund-job, der Download und das speichern am richtigen Speicherort auf meinem computer.

    • CVS speichert keine Binär-Dateien effizient. Jedoch, SVN (und ich würde vermuten, Git, Mercury usw) speichert alles, was in einem effizienten binären format, auch text-Dateien.
    • Standardmäßig Mercurial nicht speichern von binären Dateien in einer effizienten Art und Weise. Es speichert die bytes, und wenn eine byte-änderungen in der Datei eine vollständige Kopie der Datei gespeichert ist, wieder. Siehe die "largefiles" Erweiterung für die Arbeit mit binären Dateien (aber es kommt mit Kompromissen)
    • Auch, maven ermöglicht die Verknüpfung von Projekten in Eclipse/intellij, wenn Sie arbeiten auf eine Bibliothek ohne mucken über den classpath auf ein Projekt, statt in der Bibliothek. Und natürlich, es verwaltet alle transitiven depedencies und kümmert sich potenziell überschneiden .jar-Dateien (nach allem, es ist ein "dependency manager") Versionierung wird einfacher, insgesamt überprüfen .Gläser in die Quellcodeverwaltung ist nur schmerzhaft.
    InformationsquelleAutor Riduidel
  3. 4

    Source-control-Systeme sind entworfen für die Abhaltung der text Quellcode. Sie kann halten binäre Dateien, aber das ist nicht wirklich das, was Sie sind entworfen, für. In einigen Fällen ist es sinnvoll, eine binäre Datei in der Quellcodeverwaltung, aber java-Abhängigkeiten sind in der Regel besser auf andere Weise gehandhabt.

    Die ideale Einstellung ist eine, die ermöglicht die Verwaltung Ihrer Abhängigkeiten außerhalb der Quellcodeverwaltung. Sie sollten in der Lage sein zu verwalten, Abhängigkeiten außerhalb der Quell-und einfach "Punkt" auf die gewünschte Abhängigkeit aus der Quelle. Dies hat mehrere Vorteile:

    • Sie können eine Reihe von Projekten, die abhängig von der gleichen binaries die ohne halten eine separate Kopie jeder binäre. Es ist üblich, für ein mittelständisches Projekt, Hunderte von Binärdateien es hängt davon ab. Dies kann dazu führen, eine große Menge der Vervielfältigung, die Abfälle lokalen und backup-Ressourcen.
    • Versionen der Binärdateien können zentral verwaltet werden, in Ihrem lokalen Umfeld oder innerhalb des Unternehmens.
    • In vielen Situationen, die source-control-server ist nicht eine lokale Ressource. Hinzufügen einer Reihe von Binär-Dateien verlangsamen, weil es erhöht die Menge der Daten, die gesendet werden müssen, über eine langsamere Verbindung.
    • Wenn Sie erstellen ein Krieg, möglicherweise gibt es einige Gläser, die Sie brauchen für die Entwicklung, aber nicht die Bereitstellung und Umgekehrt. Eine gute dependency-management-tool können Sie behandeln diese Art von Fragen einfach und effizient.
    • Wenn Sie je auf eine binäre Datei, die von anderen für Ihre Projekte, es können sich Häufig ändern. Das heißt, Sie könnten ständig überschreiben der binären mit einer neuen version. Seit version control wird weiter jede Kopie, könnte es schnell wachsen zu einer unüberschaubaren Größe--besonders wenn Sie jede Art von kontinuierliche integration oder automatisierte build-Skripte erstellen diese Programme.
    • Ein dependency-management-system bietet ein gewisses Maß an Flexibilität in wie Sie sind abhängig von Binärdateien. Zum Beispiel auf Ihrer lokalen Maschine, möchten Sie vielleicht abhängen auf die aktuellste version einer Abhängigkeit, wie es sitzt auf dem Datei-system. Jedoch, wenn Sie die Bereitstellung Ihrer Anwendung Sie möchten, dass die Abhängigkeit verpackt als einem Glas und Sie in Ihrer Datei.

    Maven die Abhängigkeit-management-Funktionen lösen diese Probleme für Sie und kann Ihnen helfen, suchen und abrufen von binären Abhängigkeiten, wie gebraucht. Ivy ist ein weiteres tool, das dies tut, aber für Ant.

    • Hallo Markus, deine ersten beiden Sätze sind wahr, mit Bezug auf CVS aber nicht für SVN (und ich würde vermuten, die meisten modernen SCMs). svnbook.red-bean.com/en/1.5/svn.forcvs.binary-and-trans.html
    • Kevin, ich weiß, dass die meisten SCMs halten können binäre Informationen. Ich sage nur, dass Sie wurden hauptsächlich gebaut für die Speicherung von text. Viele der tools, die Sie verwenden werden, mit einem SCM-sind nur sinnvoll, wenn der Umgang mit text-Dateien. Auch wenn Sie die Speicherung großer .jar-Dateien in Ihre SCM-und Sie verändern (in der mit dem Namen und Inhalt), wie Sie ein upgrade auf verschiedene Versionen, Ihre repository kann sehr aufgebläht, mit all den verschiedenen Versionen der Binärdateien. In einigen Fällen ist dies möglicherweise nicht wichtig, aber in anderen kann es verlangsamen Ihre Geschäftsprozesse und machen Sie backups zu einem problem werden.
    • Hallo Mark, mit Ausnahme der alten CVS, es ist nicht wahr, dass die SCMs sind gebaut für die Speicherung von text. Soweit Speicher betroffen ist, alle Dateien sind Binär und Sie nutzen eine effiziente binäre differencing Algorithmus.
    • Nehmen Sie den code, geht in ein SCM-und unterteilen es in drei Abschnitte: 1. der gesamte code, der in Erster Linie für die Arbeit mit text. 2. der gesamte code, der in Erster Linie für das arbeiten mit Binär-Dateien 3. alle der code ist generisch und für beide Arten von Dateien. Ich behaupte immer noch, dass die Menge an code, die in 1 und 3 wird größer sein als der code in 2 und 3. Dies ist, weil einige der kompliziertesten Teile eines SCM-Systems befassen sich mit der Kombination verpasst-etwas, das Sie nicht mit binären Dateien. So, während Sie arbeiten sehr gut mit binären, das ist nicht Ihre primäre Zweck oder design.
    • Ich würde hinzufügen einen Punkt - richtig konfiguriert-dependency-management-Systeme sind in der Lage zu verfolgen, transitive Abhängigkeiten, wenn Sie nicht, erhalten Sie in der Regel ClassNotFound zur Laufzeit, und oft nur, wenn Sie eine Ecke die Funktionalität des Produkts, die nicht Teil der automatisierten tests.
    InformationsquelleAutor Mark
  4. 3

    Sind binäre Dateien:

    • Ist es besser, die Quelle an, denn das ist, was Sie verwenden - source-control für.
    • Kann das system nicht sagen, welche Unterschiede zwischen den Dateien
    • Sie zu einer Quelle von merge-Konflikten, im Falle Sie sind zusammengestellt aus der Quelle in das gleiche repository.
    • bei Einigen Systemen (z.B. SVN) befassen sich nicht sehr gut mit großen binären Dateien.

    In anderen Worten, besser die Quelle, und passen Sie Ihre build-Skripte, um damit alles funktioniert.

    InformationsquelleAutor vdboor
  5. 2

    Die Entscheidung zu verpflichten, jar-Dateien zu SCM ist in der Regel beeinflusst durch das build-Werkzeug verwendet wird. Bei Verwendung von Maven in einer herkömmlichen Art und Weise, dann Sie haben nicht wirklich die Wahl. Aber wenn dein build-system erlaubt Ihnen die Wahl, ich denke, es ist eine gute Idee, zu verpflichten, Ihre Abhängigkeiten SCM-neben dem Quellcode, der von Ihnen abhängt.

    Dies gilt für third-party-jars und in-house-Gläser, die sind auf einen separaten release-Zyklus zu Ihrem Projekt. Zum Beispiel, wenn Sie eine in-house-jar-Datei mit der Allgemeinen utility-Klassen, die ich Begehen würde, dass SCM nach jedem Projekt, das es verwendet.

    Wenn CVS zu benutzen, bewusst sein, dass es nicht der Bearbeitung binäre Dateien effizient. Ein SVN-repository, macht keinen Unterschied zwischen binary und text-Dateien.

    http://svnbook.red-bean.com/en/1.5/svn.forcvs.binary-and-trans.html

    Update in Reaktion auf die Antwort geschrieben von Mark:

    WRT Punkt 1: ich würde sagen, es ist nicht sehr üblich, für die sogar ein großes Projekt, Hunderte von Abhängigkeiten. In jedem Fall, disk usage (halten Sie eine separate Kopie von einer Abhängigkeit in jedes Projekt, das es verwendet) sollte nicht Ihr Hauptanliegen. Speicherplatz ist Billig im Vergleich mit der Menge an Zeit verloren, die den Umgang mit der Komplexität von einem Maven-repository. In jedem Fall, ein lokales Maven-repository, verbrauchen weit mehr Platz als nur die Abhängigkeiten, die Sie tatsächlich nutzen.

    Kugel 3: Maven wird nicht speichern Sie die Wartezeit für Netzwerk-traffic. Das Gegenteil ist wahr. Mit Ihren Abhängigkeiten im source-control, machen Sie Kasse, dann schalten Sie von einem Zweig auf einen anderen. Sie werden nur sehr selten benötigen, zur Kasse die gleichen Gläser wieder. Wenn Sie dies tun, es dauert nur wenige Minuten. Der Hauptgrund Maven ist eine langsame build-tool ist mit allen Netzwerk-Zugang tut es auch, wenn es keine Notwendigkeit.

    Punkt 4: Dein Punkt hier ist nicht ein argument gegen die Speicherung von Gläsern in SCM und Maven ist nur einfach, sobald Sie gelernt haben, und es ist nur effizient bis zu dem Punkt, wenn etwas schief geht. Dann wird es schwierig und die Effizienz, die Gewinne können schnell verschwinden. In Bezug auf die Effizienz, Maven hat einen kleinen Kopf, wenn die Dinge richtig funktionieren und ein großer Nachteil, wenn Sie nicht.

    Punkt 5: Version control Systeme wie SVN nicht halten Sie eine separate Kopie von jeder version jeder Datei. Es speichert Sie effizient wie deltas. Es ist sehr unwahrscheinlich, dass Ihr SVN-repository wächst zu einer 'unüberschaubaren' Größe.

    Punkt 6: Dein Punkt hier ist nicht ein argument gegen die Speicherung von Dateien ist SCM. Die Verwendung Fall, die Sie erwähnen, können behandelt werden, ebenso einfach durch eine eigene Ant-build.

    InformationsquelleAutor Kevin Stembridge
Schreibe einen Kommentar