我有一个POM,它声明了我的项目常见的Web应用程序。我使用它作为所有Web应用程序的父级。
只有在包装发生战争时才能激活配置文件吗?我尝试了属性方法,但这不起作用(因为它不是系统/环境属性)。
由于构建失败,我可以在安装POM时简单地禁用该配置文件,但我希望它本身更智能。
沃尔特
答案 0 :(得分:12)
您可以简单地检查src / main / webapp的存在。使用Maven标准目录布局的每个Web应用程序都应包含此文件夹。所以你要避免不必要的虚拟文件。
<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是否存在。这应该明确地确定一个战争项目。
对于我自己,我在我的常用超级pom中使用此配置来为不同的项目类型配置maven-eclipse-plugin。这非常方便在我们组织中的同一项目类型上获得同质的eclipse配置,特别是当开发人员直接运行eclipse:eclipse on multi-module-projects时。
答案 1 :(得分:5)
我知道这不是直接回答你的问题,但像这样的问题的通常解决方法是使用专门化(与类一样)。
因此,您的MasterPom具有所有常见行为。
扩展MasterPom的MasterWarPom(它是它的父级),并在此处放置任何“打包是战争”专业。
同样你可以拥有MasterJarPom等......
这样就可以很好地区分差异。
答案 2 :(得分:3)
没有干净的方法,父模块无法知道孩子的包装。 (非干净的解决方案将涉及创建一个解析子模块的pom等插件。)
答案 3 :(得分:0)
我能够为这些排序方案提出的最好的方法是使用基于文件的激活触发器。 例如我的父母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战项目标志物” 激活个人资料
这看起来很愚蠢,但工作相当可靠 - 如果不同的人或系统进行构建,使用属性激活是不可靠的, - 继承特定于类型的父类对我来说变得有点麻烦,因为祖父母pom相对频繁地更改版本,因为它用于定义公共依赖项的“标准”或首选版本,这反过来需要所有类型特定的相应版本没有变化的父母除了祖父母版本
答案 4 :(得分:-2)
试试这种方式?
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>