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

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

22 голосов
/ 01 октября 2009

Сценарий:

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

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

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

Ответы [ 3 ]

8 голосов
/ 29 августа 2012

Чтобы расширить ответ @ 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>

Теперь дочерний объект, наследующий от этого родительского POM по умолчанию, будет использовать 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 приходят на ум.

5 голосов
/ 06 октября 2009

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

5 голосов
/ 01 октября 2009

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

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

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

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

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