Maven - активировать дочерний профиль на основе свойства

Сценарий:

  • Учитывая
    • Родительский POM, который определяет профиль и дочерний элемент (как модуль)
    • Проект ребенка, который будет использовать профиль, ссылаясь на родительский POM.
  • Цель состоит в том, чтобы пропустить выполнение профиля в родительском объекте и выполнить его только в дочернем
  • Профиль имеет раздел активации <activation><property><name>foo</name></property><activation>
  • Поскольку родительский элемент не определяет свойство foo - профиль неактивен и не будет выполнен для родительской сборки
  • Теперь я определяю <properties><foo>true</foo></properties> у ребенка с надеждой на то, что свойство будет поднято при выполнении дочерней сборки и будет активирован профиль. Нет такой удачи. Профиль никогда не активируется, что говорит мне, что свойство никогда не устанавливается.
  • Просто отметить: mvn package -Dfoo=true активирует профиль как в родительском, так и в дочернем

Я пытаюсь сделать невозможное или просто делать это неправильно?

P.S. Hmmm - даже если я определяю свойство в родительском, профиль не запускается. Что дает?

Ответы

Ответ 1

Чтобы расширить ответ на @rich-seller и @Bostone самостоятельно, кажется, что невозможно установить параметры, в которых родительский POM определяет несколько профилей в качестве альтернатив, а дочерние POM выбирают один из этих профилей по умолчанию, позволяя вам временно переопределить выбор для ребенка (т.е. на CLI). Рассмотрим родительский POM для проектов, которые используют некоторую фреймворк и связанный с ними плагин, обе версии которого мы можем предположить, определяются свойствами:

<profiles>
  <profile>
    <id>newest</id>
    <activation>
      <activeByDefault>true</activeByDefault>
    </activation>
    <properties>
      <framework.version>2.0</framework.version>
      <plugin.version>2.0</plugin.version>
    </properties>
  </profile>
  <profile>
    <id>older</id>
    <activation>
      <property>
        <name>older.framework</name>
        <value>true</value>
      </property>
    </activation>
    <properties>
      <framework.version>1.1</framework.version>
      <plugin.version>1.1</plugin.version>
    </properties>
  </profile>
</profiles>

Теперь дочерний объект, унаследованный от этого родительского ПОМ по умолчанию, будет использовать 2.0, как и следовало ожидать, и -Polder или -Dolder.framework=true будет работать, чтобы попытаться создать его с помощью старой структуры (например, для проверки совместимости). Однако вы не можете писать в дочернем POM

<properties>
  <older.framework>true</older.framework>
</properties>

и активировать профиль older. Вы можете использовать активацию на основе файлов, чтобы этот модуль был построен против 1.1, если newest не были активны по умолчанию, но тогда нелегко временно запустить его против 2.0: насколько я знаю, как older, так и newest профили будут активны, если вы прошли -Pnewest, поэтому вам нужно явно отключить другие профили, которые необоснованны, если у вас их дюжина. Таким образом, нет никакого решения, кроме как скопировать информацию профиля в дочерний POM:

<properties>
  <framework.version>1.1</framework.version>
  <plugin.version>1.1</plugin.version>
</properties>

в этот момент -Pnewest не будет работать, чтобы переопределить эти свойства, поэтому вам нужно использовать -Dframework.version=2.0 -Dplugin.version=2.0.

Другими словами, профили полезны, только если все дочерние модули могут использовать один и тот же профиль (здесь newest) по умолчанию. Если некоторые из них обычно построены с 1.1, а некоторые с 2.0, профили бесполезны.

Похоже, что это прецедент для расширения ядра Maven или, возможно, расширения для построения Maven 3. http://docs.codehaus.org/display/MAVEN/Custom+Profile+Activators и https://github.com/maoo/maven-tiles приходят на ум.

Ответ 2

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

В этом случае вы используете бит-22, если вы не можете передать свойство из командной строки, указать активацию профиля в ваших настройках. xml (как правило, это не отличная идея) или использовать обходной путь в предыдущем ответе , чтобы использовать наличие файла маркера.

Одна из последних альтернатив, если вы находитесь на Maven 2.1.0+, - это деактивировать профиль через командную строку только для родительского POM, это, по-видимому, не идеально.

Вы можете деактивировать профиль с помощью символа '!' или '-' следующим образом:

mvn install -P !profile-1,!profile-2

Ответ 3

Чтобы напрямую ответить на мой собственный вопрос: в многомодульной сборке все свойства задаются до запуска сборки, поэтому невозможно активировать/деактивировать профиль в одном из модулей во время сборки, основываясь на настройке propety в дочернем POM. Однако, если вы ищете способ сделать это, используя другие средства, пожалуйста, прочитайте этот комментарий