Профиль Maven - Активировать профиль в зависимости от упаковки

У меня есть POM, который объявляет материал веб-приложения, который является общим для моих проектов. Я использую это как родительский для всех веб-приложений.

Можно ли активировать профиль только в том случае, если упаковка является войной? Я пробовал подход к свойствам, но это не работает (поскольку это не свойство system/environment).

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

Вальтер

Ответ 1

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

Ответ 2

Вы можете просто проверить наличие src/main/webapp. Каждое веб-приложение, использующее стандартную раскладку каталога Maven, должно содержать эту папку. Поэтому вы избегаете ненужных фиктивных файлов.

<profile>
    <id>custom-profile-eclipse-project-generation-webapp</id>
    <activation>
        <file>
            <exists>${basedir}/src/main/webapp</exists>
        </file>
    </activation>
    <build>
    </build>
</profile>

Более точным вы также можете проверить наличие ${basedir}/src/main/webapp/WEB-INF/web.xml. Это должно окончательно определить военный проект.

Для себя я использую эту конфигурацию в своем общем супер-пом, чтобы настроить maven-eclipse-plugin для разных типов проектов. Это очень удобно для получения однородных конфигураций затмений над одним и тем же типом проекта в нашей организации, особенно когда разработчики просто запускают eclipse: eclipse в мультимодульных проектах.

Ответ 3

Я знаю, что это не отвечает на ваш вопрос напрямую, но обычным обходным решением таких проблем является просто использование специализации (как и для классов).

Итак, у вас есть MasterPom со всем распространенным поведением.

MasterWarPom, который расширяет MasterPom (является ли он родительским) и предлагает здесь любую специализацию "упаковка - война".

Кроме того, у вас может быть MasterJarPom и т.д.

Таким образом, различия расщепляются красиво.

Ответ 4

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

<profile>
   <id>maven-war-project</id>
   <activation>
     <file><!-- add a file named .maven-war-project-marker to webapp projects to activate this profile -->
       <exists>${basedir}/.maven-war-project-marker</exists>
     </file>
   </activation>
   <build>
     <plugins>
   <!-- configuration for webapp plugins here  -->
     </plugins>
   </build>

и проекты webapp, которые наследуются от этого родителя, содержат файл с именем '.maven войны-проект-маркер' который активирует профиль

Это выглядит довольно тупо, но работает достаточно надежно, тогда как - использование активации является ненадежным, если другой человек или система выполняет сборку, - наследование от родителей, специфичных для типа, стало для меня немного громоздким, поскольку grandparent-pom изменяет версию относительно часто, поскольку она используется для определения "стандартных" или предпочтительных версий общих зависимостей, которые, в свою очередь, требуют соответствующих выпусков всех типов родители без изменений, кроме версии для бабушки и дедушки

Ответ 5

Попробуйте таким образом?

mvn package -Dmaven.test.skip = true -Dwar

<project ×××××>
<modelVersion>4.0.0</modelVersion>
<parent>
    <groupId>××××</groupId>
    <artifactId>×××××</artifactId>
    <version>×××××</version>
    <relativePath>../../</relativePath>
</parent>
<artifactId>×××××</artifactId>
<name>${project.artifactId}-${project.version}</name>
<description>${project.artifactId}-${project.version}</description>
<properties>
    <packaging.type>jar</packaging.type>
</properties>
<profiles>
    <profile>
        <activation>
            <property>
                <name>war</name>
            </property>
        </activation>
        <properties>
            <packaging.type>war</packaging.type>
        </properties>
        <build>
            <finalName>ROOT</finalName>
        </build>
    </profile>
</profiles>
<packaging>${packaging.type}</packaging>
<dependencies>
    <dependency>
        ... ...
    </dependency>
    ... ... 
</dependencies>