Für:
Gegen:
Im Allgemeinen ist es also ein großartiger Weg für das schnelle Prototyping, kann aber in einem größeren Projekt in einer gewissen Weise funktionieren.
Ein legitimer Grund, den ich am Arbeitsplatz gesehen habe, ist die Tatsache, dass ein Hersteller Hotfix-Jars zur Verfügung stellt, die der ursprünglichen Version im Klassenpfad vorausgehen müssen.
Diese Anwendung wird jedoch über Java-Webstart (jnlp) gestartet und ab Java-Version 6 ist die Reihenfolge der JAR-Dateiabhängigkeiten nicht mehr gewährleistet.
Daher ist die einzige Möglichkeit, sicherzustellen, dass die duplizierten Klassendateien in der richtigen Reihenfolge sind, sie in ein Uber-Jar zu packen, wobei die neuesten gepatchten Klassendateien beibehalten und ältere Duplikate verworfen werden.
Umverteilungslizenzen, die auf Abhängigkeiten anwendbar sind, sind ein Hauptgrund gegen den Aufbau eines "Uber" -Glases. Wenn man ein "Uber" -Glas erstellt, erfolgt die Verteilung von Abhängigkeiten über die Verteilung des "Uber" -Glases. Und in Regionen, wo die Rechtsprechung dieses Szenario nicht angemessen abdeckt, könnte man sich für die Haftung öffnen.
Außerdem können einige im Handel erhältliche Abhängigkeiten das Umpacken von Abhängigkeiten verhindern, insbesondere wenn die ursprüngliche Verteilung nicht beibehalten wird.
PS: Dies ist kein Rechtsrat. Jeder, der dies liest und davon abhängig ist, geschäftliche Entscheidungen zu treffen, sollte sich an einen Anwalt wenden.
Verteilung FTW! Es ist so viel einfacher für den Benutzer zu einem zusammengerollt.
Für:
Gegen:
Wenn es sich um eine kleine Utility-Anwendung handelt, werde ich sie im Allgemeinen in ein einziges Glas bündeln. Für größere Anwendungen (die wahrscheinlich sowieso einen Installer benötigen), oder wenn es eine Bibliothek für andere ist, werde ich nicht stören. Es wird nur ein weiteres Glied in der Kette von Dingen sein, die brechen können.