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

Question

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

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

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

Walter

Answer 1

Вы можете просто проверить наличие 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: eclipse в многомодульных проектах.

Answer 2

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

Таким образом, у вас есть MasterPom со всем распространенным поведением.1003 *

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

Аналогично, вы можете иметь MasterJarPom и т. Д.как хорошо разделены различия.

Answer 3

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

Answer 4

Попробовать таким образом?

пакет mvn -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>

Answer 5

Лучшее, что я смог придумать для таких сценариев, - это использование триггера активации на основе файлов.например, у моего родительского 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>

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

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