Много ли унаследованных профилей с одним плагином в Maven - хорошая идея? - PullRequest
4 голосов
/ 14 января 2009

В нашей инфраструктуре у нас есть много маленьких Java-проектов, созданных Maven2. Каждый проект имеет свой собственный файл pom.xml, который в конечном счете наследуется от родительского pom нашей «основной» компании.

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

Примеры:

  • Профиль ' sources ' выполняет maven-source-plugin , чтобы создать банку источников проекта.
  • Профиль ' clover ' выполняет maven-clover2-plugin для генерации отчета Clover. Он также встраивает наш файл лицензии Clover, поэтому его не нужно повторно указывать в дочерних проектах.
  • Профиль ' fitnesse ' выполняет fitnesse-maven-plugin для запуска тестов фитнеса, связанных с проектом. Он содержит хост-сервер и порт фитнес-сервера и другую информацию, которую не нужно повторять.

Используется для указания сборок на нашем CI-сервере, например:

mvn test -P clover
mvn deploy site-deploy -P fitnesse,sources

и т. Д.

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

Однако, существуют ли какие-либо опасности или подводные камни в продолжении этого подхода (очевидный или нет)? Может ли этот тип функциональности быть лучше реализован или выражен по-другому?

Ответы [ 3 ]

1 голос
/ 31 июля 2009

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

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

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

1 голос
/ 14 января 2009

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

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

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

0 голосов
/ 15 января 2009

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

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

Что касается а), я думаю, что профили предназначены для разных сред сборки или выполнения. Вы можете зависеть от локально установленного программного обеспечения, где вы будете использовать профиль для определения пути к исполняемому файлу в соответствующих средах. Или у вас могут быть профили для разных конфигураций среды выполнения, таких как «разработка», «тестирование», «производство». Подробнее об этом можно узнать по http://maven.apache.org/guides/mini/guide-building-for-different-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 могла бы быть лучшим подходом. Использование профилей может стать проблемой, когда в игру вступают «настоящие» профили для разных сред выполнения или сборки. В результате вы можете получить смесь из профилей, которая может привести к путанице, где профили означают совершенно разные вещи (например, «тест» будет обозначать среду, а «фитнес» - цель) Если бы вы просто назвали цели явно, я думаю, это было бы очень ясно и гибко. Запоминание имен плагинов / целей не должно быть более сложным, чем запоминание имен профилей.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...