file WAR diversi, risorse condivise

Supponiamo di avere diverse applicazioni che condividono lo stesso codice e la maggior parte delle altre risorse, ma hanno un aspetto un po 'diverso, alcune etichette cambiano, ecc. (Pensate a branding). Se each applicazione web deve andare nel proprio file WAR, where metti le risorse condivise?

Utilizzo già il classpath per condividere classi e file di properties;. Ma cosa su file di javascript e css? È il modo migliore per creare e distribuire un file WAR extra che servirà a questi file condivisi a qualunque altra applicazione richiede?

Ho anche pensato a uno script di build che fa una magia e da una sorgente comune esplica le (leggermente) diverse WAR, ma non mi piace perché semplicemente complica le cose inutilmente quando hai bisogno di build / testare / eseguire una singola applicazione .

Qualsiasi altro suggerimento e trucco sarebbero apprezzati.

È ansible distribuire entrambe le WAR nella stessa EAR e mettere le risorse comuni nell'EAR. Quindi mettere le dependencies appropriate nel manifesto delle applicazioni web per collegarsi ai file di jar nell'orecchio.

Una strategia che ho visto usata per tali configurazioni di linee di prodotti utilizza sovrapposizioni di WAR durante la costruzione con maven . Si definisce una WAR comune che contiene la roba comune e lo sovrasta con quelle altre WAR che contengono la roba specifica per generare vari WAR per each applicazione. Questo metodo è probabilmente più utile se si distribuiscono le varianti WAR su macchine diverse. Ma non sono sicuro se posso effettivamente raccomandare questo.

Ricorda di specificare la configuration delle sovrapposizioni se effettivamente sovrascrive le cose, in quanto altrimenti l'ordine dominante non è deterministico. Può anche cambiare con un aggiornamento del plug-in di guerra-guerra. (Ha fatto nel nostro caso.)

Se non si desidera passare l'itinerario EAR, utilizzando tomcat, etc; ci sono altri modi per raggiungere la consistenza desiderata.

Se vuoi condividere solo js e css, guarda il pacchetto: tag . Potresti ospitare i .js e css da un server apache, impostare il tuo httpd.conf in modo che i tuoi webapps possano chiamarlo, quindi utilizzare il pack: tag dalle sue guerre di applicazione – DRY e compressione in un solo passaggio.

Grazie per le risposte finora, ma temo che ho dimenticato di menzionare che le WAR saranno distribuite in ambienti diversi che sono completamente isolati l'uno dall'altro.

Quindi forse avendo una comune WAR distribuita accanto all'applicazione effettiva è l'unica opzione. Penso che andrò con quanto segue:

  • WAR1, WAR2 contenente roba specifica app
  • CommonWAR contando roba comune (senza scherzare)
  • EAR1: WAR1 + CommonWAR, da distribuire in env1
  • EAR2: WAR2 + CommonWAR, da distribuire in env2

Aggiornare

Sì, ancora una volta. Ho effettivamente cambiato la mia mente (ancora :)). Attualmente sto cercando (qui più prudente):

  • (Comune) WAR: contiene l'applicazione, comune (la maggior parte) + alcune cose specifiche
  • EAR1: CommonWAR + file di configuration specifica per env1
  • EAR2: CommonWAR + file di configuration specifici per env2

Il file di configuration viene prelevato dalla WAR. È sul path di class EAR e contiene solo un'applicazione di properties; con un valore. La singola WAR utilizzerà, ove opportuno, queste informazioni per distinguere tra le due applicazioni (config, fogli di stile, …).

Con la mia soluzione di EAR1 = CommonWAR + WAR1, EAR2 = CommonWAR + WAR2, era troppo difficile o imansible cercare risorse statiche in CommonWAR senza utilizzare un URL web (ad es. Immagini in documenti PDF generati con iText).

Che ne dite di mettere i tuoi css e js nel path di class e servirli con un servlet? Quindi puoi build le risorse comuni come un jar e che il jar può anche contenere il servlet (il dispatcher di risorse se vuoi) e i file di guerra possono contenere il file jar nella cartella WEB-INF / lib.