Как переопределить конфигурацию maven-release-plugin в одном дочернем модуле - PullRequest
8 голосов
/ 10 июня 2011

У меня есть многомодульная сборка maven, в которой один из дочерних модулей требует выполнения дополнительной цели в рамках выпуска. Но похоже, что любая конфигурация maven-release-plugin в дочернем модуле игнорируется в пользу конфигурации по умолчанию в родительском модуле.

Это фрагмент из дочернего модуля. Конфигурация плагина такая же, как и в разделе pluginManagement родительского pom, но без пользовательского элемента.

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-release-plugin</artifactId>    
    <version>2.1</version>
    <configuration>
        <tagBase>http://mycompany.com/svn/repos/myproject/tags</tagBase>
        <goals>deploy myCustomPlugin:myCustomGoal</goals>
    </configuration>
</plugin>

Так может ли дочерний модуль переопределить конфигурацию родителя и добавить дополнительные цели?

Maven версия 2.2.1

Ответы [ 2 ]

11 голосов
/ 05 августа 2011

Использование combine.children="append" combine.self="override"

POM родителей

<configuration>
  <items>
    <item>parent-1</item>
    <item>parent-2</item>
  </items>
  <properties>
    <parentKey>parent</parentKey>
  </properties>
</configuration>

Детская кроватка

<configuration>
  <items combine.children="append">
    <!-- combine.children="merge" is the default -->
    <item>child-1</item>
  </items>
  <properties combine.self="override">
    <!-- combine.self="merge" is the default -->
    <childKey>child</childKey>
  </properties>
</configuration>

Результат

<configuration>
  <items combine.children="append">
    <item>parent-1</item>
    <item>parent-2</item>
    <item>child-1</item>
  </items>
  <properties combine.self="override">
    <childKey>child</childKey>
  </properties>
</configuration>

Подробнее см. в этом блоге

3 голосов
/ 03 августа 2011

Да и нет.Конечно, дочерний pom может переопределить конфигурацию плагина, указанного его родителем, и я должен предположить, что вы сделали это правильно, потому что в этом нет ничего сложного.Если вы проверите вывод mvn help:effective-pom, вы сможете ясно увидеть, что этот модуль имеет различные настройки для плагина релиза.

Проблема, с которой вы столкнулись, связана с поведением плагина релиза.Как правило, если вы запускаете цель или этап - например, mvn compile - из корневого модуля вашего проекта, он сначала запускает эту цель / этап для корневого модуля, а затем для всех модулей в порядке реактора, почти какесли бы вы запускали его в каждом модуле самостоятельно.Любые настройки, добавленные в дочерние модули, вступают в силу, как и ожидалось.Когда вы запускаете плагин релиза, он запускает only в корневом модуле.Он не работает ни в одном из дочерних модулей.Вместо этого, запуск его в корневом модуле разветвляет новую сборку с использованием тех же настроек, что и в корневом модуле, который работает для всех остальных модулей почти одинаково, за исключением того, что он использует конфигурацию корневого модуля для всех модулей.Я не знаю точной семантики, но я полагаю, что это аналогично тому, как вы вручную запускаете цели выпуска для каждого дочернего элемента и определяете параметры конфигурации в качестве системных свойств в командной строке: независимо от того, как дочерний модуль конфигурирует плагин выпуска,Аргументы командной строки win.

Я сам никогда не занимался этой проблемой, и трудно сказать, не зная точно, чего вы пытаетесь достичь.Возможно, если вы сможете выразить то, что вы хотите сделать в этом специальном модуле, в качестве профиля, то вы можете добавить профиль в свои goals и или preparationGoals.С другой стороны, есть arguments опция для подготовки и выполнения целей, с которой вы могли бы справиться с некоторыми уловками.

...