2009-10-01 2 views
20

Сценарий:Maven - активировать профиль ребенка на основе собственности

  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 активирует профиль в обоих родителей и ребенка

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

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

ответ

7

Чтобы расширить ответ на вопрос @ богатого продавца и самоответствие @ Бостона, кажется, что невозможно установить установку, где родительский 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, поэтому вам нужно явно указать disable другие профили, которые необоснованны, если у вас их дюжина. Так что нет просто никакого решения, кроме как скопировать информацию профиля на ребенка 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 приходят на ум.

+0

Yep. Я принимаю это, поскольку он основывается на моем ответе, и я вообще не люблю принимать свои собственные – Bostone

+0

Очень полезная информация. И спасибо за отзыв о активации на основе файлов; что решило мою проблему очень чисто. – Allan

5

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

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

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

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

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

Я так боялся. На самом деле кажется, что выполнение профиля установлено и не может быть изменено после начала сборки (даже с файлом маркера). С деактивацией, к чему относятся эти -1 и -2? Если у меня есть родительский элемент и дочерний элемент, а «сборка» профиля, можно предположить, что отменить профиль на родительском? (В моих тестах это не так) 'mvn install -P! Buiild-1' – Bostone

+0

Я не понимаю. Почему для вас не срабатывают триггеры '' или ''? –

+0

Примером является деактивация двух профилей, называемых «профиль-1» и «профиль-2», для «-1» или «-2» нет особого значения. В вашем случае это будет просто 'mvn install -P! Build' –

5

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

Смежные вопросы