Веб-приложение Javascript и сервер Java, построить все в Maven или использовать Grunt для веб-приложения?


97

Мы делаем веб-приложение с AngularJS, и нам нравится идея использовать Bower для управления зависимостями и Grunt для создания, запуска тестов и т. Д. ( Yeoman )

Сервер выполнен на Java с использованием Maven, поэтому, конечно, мы хотели бы, чтобы все было просто mvn install(веб-приложение + сервер)

Итак, какой подход вы выбрали и почему?

1) Рассматривайте их как два разных приложения, что на самом деле так и есть. Поэтому допустимо использование различных строительных методов / инструментов.

2) Забудьте о Grunt Bower, используйте плагины Maven для сборки, запуска тестов, управления зависимостями для веб-приложения. Если это так, то какие?

3) Используйте плагин Maven exec для вызова Grunt для создания интерфейсного веб-приложения. Я считаю это скорее взломом, чем решением.

4) Другое.

Подход, который проще интегрировать с Jenkins, является плюсом.

Заранее спасибо!


2
Спустя 3 года интеграция инструментов явно улучшилась. Этот плагин maven, кажется, охватывает большинство вещей: github.com/eirslett/frontend-maven-plugin
Earcam

Ответы:


73

Поработав какое-то время практически со всеми инструментами конвейера ресурсов в наборе инструментов Java, я пришел к нескольким выводам:

Инструменты на основе Java

Существует несколько инструментов, но самыми популярными являются JAWR и Wro4J. Самая большая проблема с обоими из них заключается в том, что они в основном основаны на Rhino (WRO4J теперь имеет некоторую поддержку Node), а Rhino медленнее, чем инструменты на основе Node. Вы также должны учитывать, что инструменты JavaScript быстро развиваются, поэтому вам следует искать инструменты, которые могут быстро перемещаться.

  • WRO4J - Великолепная поддержка, отличная интеграция с Maven И Eclipse, обширный список плагинов и достаточно гибкая структура, чтобы вы могли написать плагин для всего, что вам нужно. Если вы ограничены конвейером ресурсов на основе Java, это наверняка путь. Проблема с Wro4j в том, что он медленный (даже когда запускает процессы Node) по сравнению с инструментами на основе Node.
    Чтобы дать некоторые реальные цифры, компиляция и объединение 25 пакетов ресурсов, содержащих LESS, CSS CoffeeScript и JavaScript, занимает около 35 секунд при использовании Rhino и ~ 15 секунд при использовании поддержки Wro4j Node на iMac 2013 с 16 ГБ оперативной памяти. Использование Grunt + Node на моем маленьком MacBook Air занимает около 2 секунд.

  • JAWR - Интеграции и список функций довольно хорош, но документация невелика, и написание собственных плагинов может быть немного сложным. Когда я изначально писал этот пост, JAWR находился в середине 4-летнего перерыва, но сейчас он снова находится в активной разработке по состоянию на январь 2014 года. Если вы решите изучить Java Tools, это заслуживает исследования.

Инструменты на основе узлов (интегрированы со сборками Ant / Maven)

  • Grunt - Это просто, имеет фантастическую экосистему плагинов и огромное сообщество. Если вам нужно что-то сделать, вы можете поспорить, что для этого есть плагин - возможно, даже тот, который написан создателями grunt. Основная критика Grunt заключается в том, что он управляется конфигурацией, что упрощает настройку, но не является «Node Way». Также стоит упомянуть, что задачи Grunt нелегко компоновать, поэтому для сложного конвейера сборки JavaScript Grunt может быть не идеальным.

  • Gulp - Gulp - быстрорастущая альтернатива Grunt. По умолчанию он параллелен и использует потоки, чтобы избежать временной записи в файловую систему, что может значительно ускорить вашу сборку. Gulp очень идиоматичен и делает упор на код> конфигурацию, и хотя это дает вам много возможностей, он не идеален для команд, у которых нет основной компетенции в JavaScript.

Единственное возможное препятствие для инструментов на основе JavaScript - это то, что вам нужно будет иметь Node , npm и grunt-cli / gulp на любой машине, которая должна выполнять компиляцию. Если у вас нет доступа к вашим машинам CI или вы не используете развертывание на основе артефактов, это может быть трудной продажей.

Интегрировать это в ваш проект Maven довольно просто, и у вас есть несколько вариантов. Вы можете использовать плагин Maven ant-run , вы можете запустить задачу ant exec и вызвать ее из Maven или, что лучше всего, вы можете просто использовать задачу maven exec .
Ниже приведен код для интеграции этого в жизненный цикл Maven с помощью плагина exec, если это кому-то полезно.

    <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
Спасибо за подробный ответ. Я думаю, что выберу инструментальные средства на основе узлов. Новичок в Grunt. Мне нравится то, что я видел до сих пор, и было бы здорово, если бы у меня было лучшее из двух миров. Я не знал о существовании WRO4J и JAWR. Еще раз спасибо.
void

wro4j объединяет процессор less4j, который представляет собой реализацию less.js на основе java, производительность которой сопоставима с собственной версией node.js.
Alex Objelean

1
Причина, по которой wro4j не так быстро работает с node.js, в основном потому, что он требует операций ввода-вывода диска для каждого выполнения. Это можно было бы улучшить, только если бы процессы на основе node.js (например, lessc) позволяли бы компиляцию ресурсов в памяти.
Alex Objelean

12
Поддерживает ли этот процесс сбой Mavenсборки в случае gruntсбоя сборки?
Снексе

6
Любая задача exec, которая не возвращается должным образом, должна завершиться ошибкой сборки. stackoverflow.com/questions/3480162/…
Баер

24

Для тех, кто все еще ищет дополнительную информацию по этой теме, у одного из создателей Yeoman есть хорошая статья (написанная через несколько месяцев после того, как этот вопрос был первоначально задан), в которой исходный ответ расширяется немного более подробно:


Двойное спасибо! Я обнаружил, что этот пост был чрезвычайно полезным, и это было больше того, что я искал,
Райан Дж. МакДонаф,

13

Тогда есть также плагин frontend-maven: https://stackoverflow.com/a/19600777/320399 Он загружает Node и NPM для вас (локально в ваш проект), загружает Grunt через этот NPM (запускаемый этим узлом), а затем запускает Grunt (через этот узел). Это самозагрузка, и вам не нужно устанавливать Node на машине для сборки проекта. Всего одна команда; mvn install.


13

Возможно, вы захотите проверить http://jhipster.github.io/ : это генератор Yeoman, который генерирует приложение, в котором Maven, Grunt и Bower работают вместе.

Это немного похоже на ваш третий вариант, но все настроено для вас, что не так просто. Он также генерирует для вас базовые сервисы AngularJS и Java REST.


1
Слишком поздно начинать мой проект со свежесгенерированным приложением. Но это здорово и очень полезно, я предоставлю некоторые решения из созданного приложения и использую в своем проекте. Спасибо!
Matsemann 04

2
На самом деле вам просто нужно включить плагин yeoman-maven-plugin, и это позволяет вам поместить все файлы конфигурации JavaScript (bower, npm, grunt) в качестве братьев и сестер в pom.xml (именно там, где эти файлы должны принадлежать IMO), и на mvn install соберет все, включая ваше веб-приложение в src / main / webapp. На перенос существующего проекта в эту структуру у меня ушло меньше получаса. Конечно, вам следует взглянуть на пример приложения на github.com/jhipster/jhipster-sample-app
raven_arkadon

4

после нескольких часов, потраченных на эту проблему, я могу сказать следующее:

maven и grunt плохо работают, но это можно сделать принудительно ..

Вот описание плагина для запуска Grunt через сборку Maven.

надеюсь, это поможет :)


Спасибо за ответ, это помогает, да, но я попробую в соответствии с ответом @Baer.
void

9
указанная сущность мертва
Петр Буткович
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.