Является ли хорошей идеей множество унаследованных профилей с одним плагином в Maven?

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

Рассмотрим эти два вопроса: а) для чего нужны профили? б) с какими альтернативными подходами мы должны сравнить ваш подход?

Что касается а), я думаю, что профили предназначены для разных сред сборки или выполнения. Вы можете зависеть от локально установленного программного обеспечения, где вы будете использовать профиль для определения пути к исполняемому файлу в соответствующих средах. Или у вас могут быть профили для разных конфигураций времени выполнения, таких как «разработка», «тестирование», «производство». Подробнее об этом можно узнать на странице http://maven.apache.org/guides/mini/guide-building-for-other-environments.html и http://maven.apache.org/guides/introduction/introduction-to-profiles.html.

Что касается б), идеи, которые приходят мне в голову:

1. запуск плагинов со свойствами командной строки. Например, mvn -Dfitnesse=true развернуть. Как хорошо известное -DdownloadSources=true для плагина eclipse или -Dmaven.test.skip=true для верного огня. Но для этого потребуется, чтобы у плагина был флаг для запуска выполнения. Не все плагины, которые вам нужны, могут иметь это.
2. Называть цели явно. Вы можете вызвать несколько целей в одной командной строке, например, "mvn clean package war:exploded". Когда фитнес выполняется автоматически (с использованием соответствующего профиля), это означает, что его выполнение привязано к фазе жизненного цикла. То есть всякий раз, когда достигается эта фаза жизненного цикла, подключаемый модуль выполняется. Вместо того, чтобы привязывать выполнение плагина к фазам жизненного цикла, вы должны иметь возможность включать плагин, но выполнять его только тогда, когда он вызывается явно. Таким образом, ваш вызов будет выглядеть как «mvn Fitnesse: run source: jar deploy».

Ответ на вопрос а) может объяснить «странность». Это просто не то, для чего предназначены профили.

Поэтому я думаю, что альтернатива 2 может быть лучшим подходом. Использование профилей может стать проблематичным, когда в игру вступают «настоящие» профили для различных сред выполнения или сборки. В конечном итоге вы получите, возможно, запутанную смесь профилей, где профили означают очень разные вещи (например, «тест» будет обозначать среду, а «фитнес» — цель). Если бы вы просто назвали цели явно, я думаю, это было бы очень ясно и гибко. Запоминание названий плагинов/целей не должно быть более сложным, чем запоминание названий профилей.

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

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

Практическая проблема, с которой вы столкнетесь, заключается в том, что, насколько я знаю, нет никакого способа иметь набор «мета» профилей, которые активируют набор подпрофилей. Если бы был хороший способ создать профиль зонтика, это была бы действительно полезная функция. Ваши профили «фитнес» и «источники» действительно должны быть приватными, активированными одним или несколькими метапрофилями. (Вы можете активировать набор по умолчанию в settings.xml для каждого разработчика)

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

В качестве прецедента, которому вы можете следовать, Maven super POM имеет определенный «профиль выпуска», который включает в себя конфигурации для исходного кода, javadoc и подключаемых модулей развертывания.

Вам следует подумать о том, чтобы следовать этому подходу, чтобы ваш профиль «fitnesse» стал «интеграционным тестом», и вы могли бы определить дополнительные плагины в этом профиле, если это потребуется позже. Точно так же профиль «клевер» можно было бы переименовать в «сайт», и вы могли бы определить дополнительные отчеты в этом профиле, например. конфигурации для плагинов JDepend, JXR, PMD.