Wie vermeidet man das Kopieren von 40M Java-Bibliotheken innerhalb einer WAR, wenn die WAR-Größe 41M ist?

Question

Momentan besteht mein Build-Prozess darin, die WAR-Datei mit allen benötigten Java-Bibliotheken unter WEB-INF/lib neu zu verpacken und dann die WAR-Datei auf den Entwicklungs-/Demo-/Produktionsserver zu kopieren, um von Tomcat erneut bereitgestellt zu werden.

Die Größe der gepackten Kriegsdatei ist ungefähr 41M und sie hat im Moment ungefähr 40M externe Java-Bibliotheken. Es muss einen besseren Weg geben. Wie hast du dieses Problem gelöst?

Meine Entwicklungsmaschine ist eine Windows-Box mit Eclipse als meine IDE und Ant als mein Build-Tool. Die Server sind alle Linux-Boxen mit Tomcat 5.5.

Sollte ich vielleicht die JAR-Dateien zum Kriegspaket auf der Serverseite hinzufügen?

Answer 1

Ich kann sehen, was Sie sagen, und hatten die gleiche Frustration mit einigen unserer Webapps, aber aus Gründen der Konsistenz würde ich vorschlagen, dass Sie die Dinge so halten, wie sie sind. Wenn Sie die Bibliotheken in das Verzeichnis tomcat/lib kopieren, können Probleme mit dem Klassenpfad des Systems und dem Klassenpfad des Webapps auftreten.

Indem Sie die Dinge so belassen, wie sie sind, sind Sie sicher, dass Sie die gleichen Dinge in der Entwicklung/Demo einsetzen, wie Sie in der Produktion sind. Das Leben ist nervig, wenn man Dinge manuell in der Produktion anpasst, oder man hat einen verrückten Fehler, weil man XYZ.jar in der Produktion von Version 1.6 auf 1.6.1_b33 aktualisiert hat und jetzt verhält es sich anders als man glaubt, ist der exakt gleiche Code auf Demo .

Wenn ich mit etwas arbeiten muss, das wichtig genug ist, um Dev/Demo/Production-Systeme zu haben, denke ich, Konsistenz ist viel mehr ein Problem als .war Dateigröße.

Answer 2

Können Sie die nicht ändernden Jars zum Java-Bibliothekspfad auf der Serverseite hinzufügen und nur die sich regelmäßig ändernden Jars in Ihren WAR einschließen?

Answer 3

Sie könnten die externen Java-Bibliotheken in das Tomcat/lib-Verzeichnis aufnehmen. Auf diese Weise bleiben sie auf dem Server.

Answer 4

Sie könnten einfach als JAR-Datei bereitstellen, Ihre Implementierungsumgebung lokal replizieren und einfach die geänderten Dateien und das Jar selbst kopieren. Der Weg ist das einzige wirkliche Problem.

Oder Sie könnten in die Einrichtung einer EAR schauen.

Answer 5

Tomcat hat ein shared/lib Verzeichnis, das der richtige Ort für globale Anwendungsabhängigkeiten ist. Diese sind jedoch für alle Anwendungen sichtbar, was sich auf das Abhängigkeitsmanagement auswirkt und möglicherweise Auswirkungen auf Dinge wie statische Variablen haben kann. Ich bin mir nicht sicher, ob Sie etwas besser in Tomcat konfigurieren können.

Eine Alternative ist der Wechsel zu einem anspruchsvolleren Web-Container. Beispiel: WebSphere Application Server Community Edition (eine blau gewaschene Version von Geronimo) unterstützt per-asset libraries. Andere freie und kommerzielle Server unterstützen dies ebenfalls. Ich weiß, WebSphere Application Server tut, und ich bin mir ziemlich sicher, dass Sie es in Glassfish tun können.

Answer 6

Ich arbeite mit der "explodierten Webanwendung" in den Entwicklungsservern und gelegentlich auch in der Produktion. Der Deployment-Prozess (basierend auf ANT) aktualisiert die JARs in WEB-INF/lib mit unseren Paketen. Nur im Entwicklungsserver aktivieren wir das Tomcat-Reload, das den Neustart der Anwendung übernimmt, wenn sich etwas ändert. Sie sollten diesen Tomcats etwas zusätzlichen permanenten Speicher zuweisen und eine Möglichkeit haben, den Server neu zu starten, da das erneute Laden Tomcat von Zeit zu Zeit zum Absturz bringen kann.

Ich weiß, es ist eine seltsame Konfiguration, aber ich kann nicht verstehen, wie ständig die 30MB (und wachsenden) unserer typischen Anwendung neu verpacken könnte besser. Eines Tages könnte der Entwicklungsdeskriptor externe Verweise auf Bibliotheken enthalten, die der Container herunterladen und zwischenspeichern kann. ??

Entschuldigung mein schlechtes Englisch.

Answer 7

@McDowell, wenn Sie diese J2EE-Server erwähnen, sollten Sie präzisieren, dass sie J2EE-Server sind (Servlet-Container + der Rest).

Wie @digitaljoel, schlage ich vor, Dinge zu behalten, wie sie sind. Es sieht so aus, als ob Sie noch nicht viele Webanwendungen implementiert haben. Die Probleme, die Sie haben, sind den Preis nicht wert (Versionskonflikte, Bereitstellungsfehler usw.).

Answer 8

Was Sie brauchen, ist ein Tool zur Versionskontrolle und ein Build-Prozess.

Verwenden Sie CSV, SVN, GIT oder was auch immer Sie passen, um Ihre Quelle unter Kontrolle zu halten. Verwenden Sie ein Build-Tool zum Erstellen Ihrer Anwendung: Maven, ant, ...

Jetzt, wenn Sie Ihre Anwendung auf Ihrem Server bereitstellen möchten, müssen Sie nur Ihre Updates auf Ihrem Computer zu committen, aktualisieren Sie Ihre Quelle auf Ihrem Server, erstellen Sie Ihre Anwendung und stellen Sie sie vom Server bereit.

Auf diese Weise muss der Server nur Ihre Änderungen laden und es sollte viel schneller sein.

Answer 9

Dafür verwenden wir das rsync-Tool (in unserem Fall cygwin unter Windows), um die Deployments auf die Server zu kopieren (auf denen linux läuft). Wir verwenden explodierte WAR/EAR-Dateien (d. H. Eine Verzeichnisstruktur namens MyApp.war anstelle einer ZIP-Datei namens MyApp.war), rsync überträgt nur die Dateien, die sich geändert haben.

Im Allgemeinen wird rsync unsere 30-40 Megabyte explodierten EARs in etwa 5 Sekunden übertragen.