Come evitare di copiare 40M di java lib all'interno di una WAR quando la dimensione di WAR è 41M?

Question

Al momento il mio processo di compilazione consiste nel riconfezionare il file war con tutte le librerie java richieste in WEB-INF/lib e quindi copiare il file war nel server di sviluppo/demo/produzione da ridistribuire da tomcat.

La dimensione del file di guerra del pacchetto è di circa 41 milioni e al momento ha qualcosa come 40 milioni di librerie java esterne. Ci deve essere un modo migliore. Come hai risolto questo problema?

La mia macchina di sviluppo è una finestra di Windows con Eclipse come IDE e Ant come strumento di creazione. I server sono tutti box Linux con Tomcat 5.5.

Devo forse aggiungere i file jar al pacchetto war sul lato server?

Answer 1

Riesco a vedere cosa stai dicendo, e ho avuto la stessa frustrazione con alcune delle nostre applicazioni web, ma per coerenza, ti suggerirei di mantenere le cose come sono. Se si copiano le librerie nella directory tomcat/lib, è possibile che si verifichino problemi con il classpath di sistema rispetto al classpath webapp.

Mantenendo le cose come sono, si è certi di distribuire le stesse cose in sviluppo/demo come in produzione. La vita fa schifo quando modifichi manualmente le cose in produzione, o hai qualche errore pazzesco perché hai dimenticato di aggiornare XYZ.jar dalla versione 1.6 alla 1.6.1_b33 in produzione e ora si comporta diversamente da quello che ritieni sia lo stesso identico codice sulla demo .

Quando si lavora con qualcosa di abbastanza vitale da avere sistemi di sviluppo/demo/produzione, ritengo che la coerenza sia molto più un problema delle dimensioni del file .war.

Answer 2

È possibile aggiungere i jar non modificabili al percorso della libreria Java sul lato server e includere solo i jar con cambio regolare nel WAR?

Answer 3

è possibile includere le librerie java esterne nella directory Tomcat/lib. In questo modo rimangono sul server.

Answer 4

Si può semplicemente distribuire come file JAR, replicare localmente il proprio ambiente di distribuzione e copiare semplicemente i file che sono stati modificati e il jar stesso. Il percorso è l'unico vero problema.

Oppure è possibile esaminare l'impostazione di un EAR.

Answer 5

Tomcat ha una directory shared/lib, che è il posto giusto per le dipendenze delle applicazioni globali. Tuttavia, questi saranno visibili a tutte le applicazioni, il che influenzerà la gestione delle dipendenze e potrebbe avere conseguenze per cose come variabili statiche. Non sono sicuro che tu possa configurare qualcosa di meglio in Tomcat.

Un'alternativa è passare a un contenitore Web più sofisticato. Ad esempio, WebSphere Application Server (versione blu di Geronimo) supportata da , supporta per-asset libraries. Anche altri server gratuiti e commerciali supportano questo. So che lo fa WebSphere Application Server e sono abbastanza sicuro che lo si possa fare in Glassfish.

Answer 6

Lavoro con l''applicazione Web esplosa' nei server di sviluppo e occasionalmente anche in produzione. Il processo di distribuzione (basato su ANT) aggiorna i JAR in WEB-INF/lib con i nostri pacchetti. Solo nel server di sviluppo, attiviamo il ricaricamento di Tomcat che si occupa di riavviare l'applicazione quando qualcosa cambia. Dovresti assegnare un po 'di memoria permanente extra a questi Tomcats e avere un modo per riavviare il server, poiché il ricaricamento potrebbe causare l'arresto anomalo di Tomcat di volta in volta.

So che è una configurazione strana, ma non riesco a capire come il costante riconfezionamento del 30MB (e in crescita) della nostra applicazione tipica possa fare di meglio. Un giorno il descrittore di sviluppo può consentire riferimenti esterni alle librerie che il contenitore può scaricare e memorizzare nella cache. ??

Scusa il mio povero inglese.

Answer 7

@McDowell, quando si parla di quei server J2EE, è necessario specificare che si tratta di server J2EE (contenitore servlet + il resto).

Come @digitaljoel, suggerisco di mantenere le cose come sono. Sembra che tu non abbia ancora fatto molta implementazione di applicazioni web. I problemi che si avranno non valgono il prezzo (conflitti di versione, errori di distribuzione, ecc.).

Answer 8

Quello che ti serve è uno strumento di controllo della versione e un processo di compilazione.

Utilizzare CSV, SVN, GIT o qualsiasi altra cosa per tenere sotto controllo la sorgente. utilizza uno strumento di compilazione per creare la tua applicazione: Maven, formica, ...

Ora, quando si desidera distribuire l'applicazione sul proprio server, è sufficiente trasferire gli aggiornamenti sul computer, aggiornare la sorgente sul proprio server, creare la tua applicazione e distribuirla dal server.

In questo modo, il server dovrà solo caricare le modifiche e dovrebbe essere molto più veloce.

Answer 9

Per questo utilizziamo lo strumento rsync (nel nostro caso, utilizzando cygwin in Windows) per copiare le distribuzioni sui server (che eseguono linux). Usiamo file WAR/EAR esplosi (ad esempio una struttura di directory denominata MyApp.war piuttosto che un file zip denominato MyApp.war), rsync trasferirà solo i file che sono stati modificati.

In generale, rsync trasferirà i nostri EAR esplosi da 30-40 megabyte in circa 5 secondi.