diferentes archivos WAR, recursos compartidos

Question

Supongamos que tiene varias aplicaciones que comparten el mismo código y la mayoría de los otros recursos, pero tienen un aspecto y sensación algo diferentes, algunas etiquetas cambian, etc. (piense en la marca). Si cada aplicación web debe ir en su propio archivo WAR, ¿dónde colocas los recursos compartidos?

Ya uso el classpath para compartir clases y archivos de propiedades. ¿Pero qué pasa con los archivos javascript y css? ¿Es la mejor manera de crear y desplegar un archivo WAR adicional que servirá estos archivos compartidos a cualquier otra aplicación que los requiera?

También pensé en un script de compilación que hace algo de magia y de una fuente común arroja las (ligeramente) diferentes WAR, pero no me gusta porque simplemente complica las cosas innecesariamente cuando necesitas construir/probar/ejecutar una sola aplicación.

Cualquier otro consejo y trucos sería apreciado.

Answer 1

Puede desplegar ambos WAR en el mismo EAR y poner recursos comunes en el EAR. A continuación, coloque las dependencias apropiadas en el manifiesto de las aplicaciones web para vincular los archivos jar al oído.

Answer 2

Si no desea ir a la ruta EAR, utilizando tomcat, etc; hay algunas otras formas de lograr la coherencia que desea.

Si quieres compartir solo js y css, mira en pack:tag. Puede alojar .js y css desde un servidor apache, configurar su httpd.conf para que sus aplicaciones web puedan llamarlo, luego use pack: tag de sus guerras de aplicaciones - DRY y compresión en un solo paso.

Answer 3

Gracias por las respuestas hasta ahora, pero me temo que olvidé mencionar que los WAR se desplegarán en diferentes entornos que están completamente aislados entre sí.

Por lo tanto, la única opción es tener un WAR común desplegado junto a la aplicación real. Creo que voy a ir con lo siguiente:

• WAR1, War2 que contiene la aplicación específica cosas
• CommonWAR containg material común (no es broma)
• EAR1: WAR1 + CommonWAR, que se desplegarán en env1
• EAR2: War2 + CommonWAR, a ser desplegados en env2

Answer 4

actualización

Sí, yo de nuevo. En realidad, he cambiado de opinión (nuevamente :)). Actualmente estoy tratando (por ser más prudente aquí):

• GUERRA (Común): contiene la aplicación, común (mayor parte) + un poco de materia específica
• EAR1: CommonWAR + fichero de configuración específica para env1
• EAR2: CommonWAR + archivo de configuración específico para env2

El archivo de configuración es recogido por WAR. Está en el classpath EAR y solo contiene una propiedad 'application' con un valor. La única GUERRA utilizará esta información cuando sea apropiado para distinguir entre las dos aplicaciones (configuración, hojas de estilo, ...).

Con mi solución de EAR1 = CommonWAR + WAR1, EAR2 = CommonWAR + WAR2, era muy difícil o imposible buscar recursos estáticos en CommonWAR sin utilizar una url web (por ejemplo, imágenes en documentos PDF generados con iText).

Answer 5

Una estrategia que he visto utilizar para tales configuraciones de línea de producto está utilizando WAR overlays al construir con maven. Define una GUERRA común que contiene las cosas comunes y la superpone con esas otras GUERRAS que contienen las cosas específicas para generar diferentes WAR para cada aplicación. Este método es probablemente más útil si despliega las variantes WAR en diferentes máquinas. Pero no estoy seguro de si realmente puedo recomendar esto.

Recuerde especificar la configuración de las superposiciones si realmente anula las cosas, ya que, de lo contrario, el orden de anulación no es determinista. Incluso podría cambiar con una actualización maven-war-plugin. (Lo hizo en nuestro caso.)

Answer 6

¿Qué le parece poner su css y js en el classpath y servirlos con un servlet? A continuación, puede compilar los recursos comunes como un jar y ese jar incluso puede contener el servlet (dispatcher de recursos si lo desea) y los archivos war pueden contener el archivo jar en la carpeta WEB-INF/lib.