Aplicación web Javascript y servidor Java, ¿compilar todo en Maven o usar Grunt para la aplicación web?


97

Estamos haciendo una aplicación web con AngularJS y nos gusta la idea de usar Bower para la gestión de dependencias y Grunt para la construcción, ejecución de pruebas, etc. ( Yeoman )

El servidor se hace con Java usando Maven, así que por supuesto nos gustaría con una simple mvn installcompilación de todo (aplicación web + servidor)

Entonces, ¿qué enfoque tomó y por qué?

1) Trátelos como dos aplicaciones diferentes, que de hecho lo son. Por lo tanto, es aceptable utilizar diferentes métodos / herramientas de construcción.

2) Olvídese de Grunt Bower, use complementos de Maven para construir, ejecutar pruebas, administrar dependencias para la aplicación web. Si ese es el caso, ¿cuáles?

3) Utilice el complemento ejecutivo de Maven para llamar a Grunt y crear la aplicación web de front-end. Veo esto más como un truco que como una solución.

4) Otro.

Un enfoque más fácil de integrar con Jenkins es una ventaja.

¡Gracias por adelantado!


2
Tres años después, la integración de herramientas obviamente ha mejorado. Este complemento de Maven parece tener la mayoría de las cosas cubiertas: github.com/eirslett/frontend-maven-plugin
earcam

Respuestas:


73

Después de trabajar con casi todas las herramientas de canalización de activos en el kit de herramientas de Java durante un tiempo, he llegado a algunas conclusiones:

Herramientas basadas en Java

Hay un puñado de herramientas, pero las más populares son JAWR y Wro4J. El mayor problema con ambos es que en su mayoría están basados ​​en Rhino (WRO4J ahora tiene algo de soporte de Node) y Rhino es lento en comparación con las herramientas basadas en Node. También debe considerar que las herramientas de JavaScript están madurando rápidamente, por lo que debe buscar herramientas que puedan moverse rápidamente.

  • WRO4J : el soporte es excelente, la integración de Maven y Eclipse es excelente, la lista de complementos es extensa y el marco es lo suficientemente flexible como para que, con un poco de esfuerzo, pueda escribir un complemento para lo que necesite. Si está confinado a una canalización de activos basada en Java, este es sin duda el camino a seguir. El problema con Wro4j es que es lento (incluso cuando inicia procesos de Nodo) en relación con las herramientas basadas en Nodo.
    Para dar algunos números del mundo real, compilar y concatenar 25 paquetes de activos que contienen LESS, CSS CoffeeScript y JavaScript toma alrededor de ~ 35 cuando se usa Rhino y ~ 15 cuando se usa el soporte de nodo de Wro4j en un iMac de 2013 con 16G de RAM. Usar Grunt + Node toma alrededor de 2 segundos en mi insignificante MacBook Air.

  • JAWR : las integraciones y la lista de funciones son bastante buenas, pero los documentos no son excelentes y escribir tus propios complementos puede ser un poco complicado. Cuando escribí originalmente esta publicación, JAWR estaba en medio de una pausa de 4 años, pero ahora está nuevamente en desarrollo activo a partir de enero de 2014. Si elige investigar las herramientas Java, vale la pena investigarlo.

Herramientas basadas en nodos (integradas con Ant / Maven Builds)

  • Grunt : es fácil, tiene un ecosistema de complementos fantástico y la comunidad es enorme. Si hay algo que necesita hacer, puede apostar que hay un complemento para ello, posiblemente incluso uno escrito por los creadores de grunt. Las principales críticas de Grunt son que se basa en la configuración, lo que hace que sea muy fácil de configurar, pero no es el "Node Way". También vale la pena mencionar que las tareas de Grunt no se pueden componer fácilmente, por lo que para una tubería de compilación de JavaScript compleja, Grunt puede no ser ideal.

  • Gulp : Gulp es la alternativa de rápido crecimiento a Grunt. Es concurrente de forma predeterminada y utiliza secuencias para evitar escrituras temporales en el sistema de archivos, lo que puede acelerar considerablemente su compilación. Gulp es muy idiomático y tiene un énfasis en la configuración del código y, aunque esto le da mucho poder, no es ideal para equipos que no tienen una competencia central en JavaScript.

El único obstáculo potencial para las herramientas basadas en JavaScript es que tendrá que tener Node , npm y grunt-cli / gulp en cualquier máquina que necesite hacer la compilación. Si no tiene acceso a sus máquinas de CI o no utiliza implementaciones basadas en artefactos, esto puede ser difícil de vender.

Integrar esto en su proyecto Maven es bastante fácil y tiene bastantes opciones. Puede usar el complemento ant-run de Maven , puede ejecutar una tarea ejecutiva de hormiga y llamarla desde Maven o, lo mejor de todo, puede usar la tarea ejecutiva de maven .
A continuación se muestra el código para integrar esto en el ciclo de vida de Maven utilizando el complemento exec si esto es útil para alguien.

    <plugin>
      <groupId>org.codehaus.mojo</groupId>
      <artifactId>exec-maven-plugin</artifactId>
      <version>1.2.1</version>
      <executions>
        <execution>
          <phase>prepare-package</phase>
          <goals>
            <goal>exec</goal>
          </goals>
        </execution>
      </executions>
      <configuration>
        <executable>grunt</executable>
      </configuration>
    </plugin>

1
Gracias por la respuesta detallada. Creo que optaré por la opción de herramientas basadas en nodos. Nuevo en Grunt Me gusta lo que he visto hasta ahora, y sería genial si pudiera tener lo mejor de dos mundos. No sabía sobre la existencia de WRO4J y JAWR. Gracias de nuevo.
anulado el

wro4j integra el procesador less4j, que es una implementación basada en Java de less.js cuyo rendimiento es comparable al del nativo de node.js.
Alex Objelean

1
La razón por la que wro4j no es tan rápido con node.js es principalmente porque requiere operaciones de E / S de disco para cada ejecución. Esto podría mejorarse solo si los procesos basados ​​en node.js (como lessc) permitieran la compilación de recursos en memoria.
Alex Objelean

12
¿Este proceso admite fallar la Mavencompilación si gruntfalla la compilación?
Snekse

6
Cualquier tarea ejecutiva que no regrese correctamente debería fallar en la compilación. stackoverflow.com/questions/3480162/…
Baer

24

Para cualquiera que todavía busque más información sobre este tema, uno de los creadores de Yeoman tiene un buen artículo (escrito unos meses después de que se hizo esta pregunta originalmente) que amplía la respuesta original con un poco más de detalle:


¡Gracias dobles! Encontré que esta publicación fue extremadamente útil y era más lo que estaba buscando,
Ryan J. McDonough

13

Luego también está el frontend-maven-plugin: https://stackoverflow.com/a/19600777/320399 Descarga Node y NPM por usted (localmente en su proyecto), descarga Grunt a través de ese NPM (ejecutado por ese Nodo) y luego ejecuta Grunt (a través de ese nodo). Es auto-bootstrapping y no necesita Node instalado en la máquina para construir el proyecto. Solo un comando; mvn install.


13

Es posible que desee consultar http://jhipster.github.io/ : es un generador Yeoman, que genera una aplicación que tiene a Maven, Grunt y Bower trabajando juntos.

Es un poco como tu tercera opción, pero todo está configurado para ti, lo cual no es tan fácil. También está generando los servicios básicos de AngularJS y Java REST para usted.


1
Es demasiado tarde para que mi proyecto comience con una aplicación recién generada. Pero esto es genial y muy útil, prestaré algunas de las soluciones de la aplicación generada y las usaré en mi proyecto. ¡Gracias!
Matsemann

2
En realidad, solo necesita incluir yeoman-maven-plugin y esto le permite poner todas las cosas de configuración de JavaScript (bower, npm, grunt) como hermanos del pom.xml (exactamente donde estos archivos deberían pertenecer en mi opinión), y luego mvn install compilará todo, incluida su aplicación web en src / main / webapp. Me tomó menos de media hora portar un proyecto existente a esa estructura. Por supuesto, debería echar un vistazo a la aplicación de ejemplo en github.com/jhipster/jhipster-sample-app
raven_arkadon

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.