递归定义Maven属性

Question

我们正在尝试重构我们的模块化Maven构建。我们引入了一个名为DEPLOYMENT_ENV的属性，它可能是“prod”，“dev”，“staging”或其他值。我们最初的想法是可以定义以下内容：

dev.jdbc.username = yoyodyne
dev.jdbc.password = 0verthruster
staging.jdb.username = cavaliers
staging.jdbc.password = 8thdim

似乎这种方法在为Maven插件配置参数时不适用。例如，DBUnit需要用户名。从语义上讲，我们原本想要的解决方案如下，但是Maven不允许以这种方式进行递归属性定义：

<configuration>
    <username>${${DEPLOYMENT_ENV}.jdbc.username}</username>
</configuration>

有没有关于参数化Maven构建的想法，以便我们可以保留大型中央属性定义列表？

- rektide

---

我非常肯定我已经做过这样的事情了，但它是在Antrun插件的 <configuration> 节点中完成的... 这个 <configuration> 位于哪个插件中？你遇到了什么行为？ - Romain Linsolas

Answer 1

您能具体说明一下遇到的问题吗？是否有任何错误提示？

我已经在我的一个pom.xml中使用了这个递归属性定义，在一个antrun插件的<configuration>中，它运行良好：

<build>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-antrun-plugin</artifactId>
            <version>1.2</version>
            <executions>
                <execution>
                    <phase>package</phase>
                    <goals>
                        <goal>run</goal>
                    </goals>
                    <configuration>
                        <tasks>
                            ...
                            <ftp server="${my-ftp-url}" userid="${ftp-${appli}-${env}-username}" password="${ftp-${appli}-${env}-password}"
                                remotedir="${remoteDir}/sources" passive="yes">
                                <fileset dir="../target/">
                                    <include name="*.tar.gz"/>
                                </fileset>
                            </ftp>
                            ...

如您所见，代码片段中使用了${ftp-${appli}-${env}-username}属性，其中${appli}，${env}和${ftp-xxx-yyy-username}是从命令行或settings.xml中获取的属性。

无论如何，正如Eugene Kuleshov所建议的那样，我会采用一组<profiles>，仅定义一些属性，使用<properties>标签或外部属性文件：

<build>
    <plugins>
        <!-- Properties loader -->
        <plugin>
            <groupId>org.codehaus.mojo</groupId>
            <artifactId>properties-maven-plugin</artifactId>
            <version>1.0-alpha-1</version>
            <executions>
                <execution>
                    <phase>initialize</phase>
                    <goals>
                        <goal>read-project-properties</goal>
                    </goals>
                    <configuration>
                        <files>
                            <file>${basedir}/${env-properties-file}</file>
                        </files>
                    </configuration>
                </execution>
            </executions>
        </plugin>
    </plugins>
</build>
...
<profiles>
    <!-- Development -->
    <profile>
        <id>dev</id>
        <activation>
            <activeByDefault>true</activeByDefault>
            <property>
                <name>env</name>
                <value>dev</value>
            </property>
        </activation>
        <properties>
            <env-properties-file>dev-environment.properties</env-properties-file>
        </properties>
    </profile>

    <!-- Homologation -->
    <profile>
        <id>hom</id>
        <activation>
            <activeByDefault>false</activeByDefault>
            <property>
                <name>env</name>
                <value>hom</value>
            </property>
        </activation>
        <properties>
            <env-properties-file>homologation-environment.properties</env-properties-file>
        </properties>
    </profile>
    ...

- Romain Linsolas

Answer 2

你可以使用相同的属性，但在 pom.xml 或 settings.xml 中声明不同的配置文件，而不是不同的属性名称。

- Eugene Kuleshov

---

我们之前一直在这样做。我们基于配置文件的方法已经失控了，不同的配置文件定义了非常不同的插件。完全同意我们可以解决独立的意大利面构建配置文件的问题，因为它们会声明不同的变量。我们正在尝试尽可能减少独立配置文件的配置，但这可能是一个好的甚至必要的地方。 - rektide

我建议创建多个只包含属性的配置文件。请注意，您可以同时激活多个配置文件，例如属性+附加插件/脚本，或仅使用默认插件的属性。 - Eugene Kuleshov