Maven и профили: использование одного и того же плагина в двух разных профилях, оба из которых активны одновременно.

Мы используем frontend-maven-plugin для использования grunt и bower в наших сборках. С плагином Frontend Maven я могу установить NPM локально, использовать Bower для загрузки библиотек Java и запускать Grunt для оптимизации и обфускации моего кода.

Вот так, с некоторым упрощением:

<plugin>
  <groupId>com.github.eirslett</groupId>
  <artifactId>frontend-maven-plugin</artifactId>
  <version>0.0.24</version>
  <executions>
    <execution>
      <id>install node and npm</id>
      <goals> <goal>install-node-and-npm</goal> </goals>
      ...
    </execution>
    <execution>
      <id>npm-install</id>
      <goals> <goal>npm</goal> </goals>
      ...
    </execution>
    <execution>
      <id>bower-install</id>
      <goals> <goal>bower</goal> </goals>
      ...
    </execution>
    <execution>
      <id>grunt-build</id>
      <goals> <goal>grunt</goal> </goals>
      ...
    </execution>
  </executions>
</plugin>

Обратите внимание, что последним выполнением является grunt-build, когда файлы JavaScript объединяются вместе, оптимизируются (удаляются возвраты, комментарии и другие вещи) и запутываются.

Это хорошо работает для релизов. Однако разработчики хотели бы развернуть войну без объединения, оптимизации и запутывания файлов JavaScript. Это поможет им в отладке. Для этого нам просто нужно удалить раздел выполнения grunt-build из конфигурации этого плагина.

Я хотел бы использовать профили для этого. Я мог бы иметь профиль под названием development, который позволяет разработчикам выполнять сборку без этого последнего раздела. Я мог бы просто скопировать и вставить этот раздел файла pom.xml, удалить последнее выполнение и поместить его в отдельный профиль. Все сделано.

Однако существует старая пословица программирования: не повторяйтесь. Я бы продублировал около 50 строк кода в моем файле pom.xml.

Что я хотел бы сделать, так это иметь способ выполнить первые три выполнения и выполнить четвертое, только если это не сборка для разработки. Я хотел бы иметь несколько других закусок и защипов в этом, а также. Например, мне пришлось бы копировать сами JavaScript, а не хрюкающие результаты. Но это достаточно просто сделать, и код не дублируется.

Это привело бы к дублированию кода, потому что мне пришлось бы определять frontend-maven-plugin с двумя конфигурациями. Один раз для профиля development и один раз для сборки стандартного релиза. Насколько я знаю, я не могу сказать, запустить эту конфигурацию frontend-maven-plugin, и если это не сборка для разработки, запустить этот экземпляр frontend-maven-plugin, который будет выполнять только ворчание.

Есть ли способ определить один и тот же плагин дважды в pom.xm и заставить Maven запускать оба экземпляра в правильном порядке?


person David W.    schedule 22.10.2015    source источник
comment
Вместо того, чтобы решать вашу проблему с помощью maven, я бы посоветовал вам начать создавать файлы MAP (html5rocks.com /en/tutorials/developertools/sourcemaps). Таким образом, ваши разработчики тестируют код, который будет запущен, но они все еще должны иметь возможность отладить его и посмотреть, что происходит. Я не раз видел, как оптимизация и минимизация ломали JavaScript. ИМХО, это хорошая практика для тестирования с использованием вашего окончательного минимизированного JS.   -  person Ardesco    schedule 23.10.2015


Ответы (2)


Вам повезло, grunt цель этого плагина определяет skip, поэтому вам нужно только установить для этого свойства значение true в вашем пользовательском профиле.

Таким образом, вам необходимо создать профиль development, который задает для пользовательского свойства skipGrunt значение true, и профиль по умолчанию, который устанавливает для него значение false.

Затем в конфигурации плагина цели grunt можно добавить

<configuration>
    <skip>${skipGrunt}</skip>
    <!-- rest of configuration -->
</configuration>

Это замечание можно сделать более общим: когда вам нужно пропустить определенное выполнение подключаемого модуля, обычно есть пользовательское свойство skip, которому вы можете присвоить значение true.

person Tunaki    schedule 22.10.2015

Позвольте мне процитировать из форум Maven:

Мой вывод заключался в том, что если просто прыгать по профилям в качестве решения каждой условной ситуации, у сборки вырастет вторая голова, как у гидры в плохом фильме ужасов, и вы действительно пожалеете об этом.

Дело в том, что профили часто являются целесообразной заменой правильного использования Maven. Их всегда следует рассматривать как крайнюю меру, если только вы не знаете, во что ввязываетесь.

В моей ситуации [...]. Профили отлично подходят для этого, но теперь я точно вижу, где голова гидры подходит к зверю, и не собираюсь делать с ними что-либо еще, если в этом нет крайней необходимости.

Я сделал свой опыт с профилями. Я поддерживаю эту точку зрения.

С концептуальной точки зрения у вас есть два проекта, которые имеют много общего. Здесь в игру вступает иерархия Maven POM с ее наследованием:

product ... parent POM
  +- pom.xml ... contains build steps apart from Grunt and all other declarations 
  +- dev
  |    +- pom.xml ... almost empty since everything's inherited from parent
  |    +- ... sources, resources, etc. ...
  +- release
       +- pom.xml ... contains Grunt build step only, everything else's inherited from parent
                      redirecting <build>/<[[test]source|resource>/]|
                          [[test]output|testresource>/]directory> to ../dev/...

См. Набор элементов BaseBuild, Ресурсы и Набор элементов сборки в справочнике POM для всех каталогов сборки, которые нужно перенаправить.

См. Maven включает еще один pom для конфигурации плагина:

Единственный правильный ответ - использовать наследование.

Я также поддерживаю это.

Если вы все же пойдете на профиль, я рекомендую называть его dev, а не development. Ваши разработчики будут благодарны вечно. :)

person Gerold Broser    schedule 22.10.2015
comment
Я не уверен, что иметь два отдельных модуля Maven для двух сред — хорошая идея. Это дублирует весь код приложения внутри модулей. - person Tunaki; 23.10.2015
comment
@ Тунаки Нет, это не так. См. dev: «... sources, resources, etc. ...». См. release: «redirecting <build directories> to ../dev/...». - person Gerold Broser; 23.10.2015
comment
Выглядит как целая куча работы и дублирования без уважительной причины для меня. - person Ardesco; 23.10.2015
comment
@Ardesco «много работы»? • Создание 2 (проектных) каталогов, • создание 2 почти пустых (POM) файлов, • объявление C&P devs в product и release POM соответственно и • перемещение dev в новую структуру? Вы шутите, не так ли? И где именно вы видите дублирование? Хорошая причина упоминается в начале моего ответа. Я также могу подробно рассказать о своем опыте работы с профилями, если выяснится, что это действительно необходимо вам и другим. - person Gerold Broser; 23.10.2015
comment
@GeroldBroserreinstatesMonica, как насчет необходимости создать еще один репозиторий git и синхронизировать его с основным? Может быть, я не понял вашей мысли, но я могу понять опасения Ардеско. Разделение проекта может быть хуже, чем сложная конфигурация. - person funder7; 26.05.2020