为什么我无法从另一个配置文件激活 Maven2 配置文件?

发布于 2024-08-21 23:15:36 字数 1978 浏览 16 评论 0原文

我有一个构建 Web 应用程序的多模块 Maven2 项目。该应用程序连接到后端服务器和数据库。我们的环境中部署了多个服务器实例,还有多个用于开发、UAT、生产等的后端和数据库实例。所以实际上,每个应用程序配置都需要这3个坐标:

  • 前端服务器
  • 后端服务器
  • DB

我是致力于应用程序配置的统一和自动化。在 Maven 中将这些不同的配置表示为配置文件是简单而明显的。然后,我可以通过激活每个组中的一个配置文件来创建特定配置,例如,

mvn -Pserver.Server1,backend.prod,db.uat clean install

这输入起来有点乏味并且容易出错 - 如果特定服务器配置错误以连接到错误的数据库,则价格可能会很高。解决此问题的一种明显方法是将所有有用的配置文件组合放入脚本文件中。

但我认为我可以通过直接从服务器配置文件激活必要的后端和数据库配置文件来更聪明。服务器配置文件位于主 pom 中,例如

<profile>
    <id>server.myserver</id>
    <properties>
        <jboss.home>D:\Programs\jboss-4.2.1.GA</jboss.home>
        <server.name>NightlyBuild</server.name>
        <hosttobind>192.168.1.100</hosttobind>
        <servlet.port>8080</servlet.port>
        ...
        <db>dev02</db>
    </properties>
</profile>

后端和数据库配置文件位于 Config 子模块的 pom 中,例如

<profile>
    <id>db.dev02</id>
    <activation>
        <property>
            <name>db</name>
            <value>dev02</value>
        </property>
    </activation>
    <properties>
        <jdbc.address>jdbc:oracle:thin:@192.168.0.101:1521:dbdev02</jdbc.address>
    </properties>
</profile>

因此理论上,由于 server.myserver 配置文件设置 db< /code> 属性设置为 dev02,这应该会触发子 pom 中 db.dev02 配置文件的激活。然而,这并没有发生。 (顺便说一句,如果两个配置文件位于同一个 pom 中,也不会)。如果我从命令行设置属性,

mvn -Ddb=dev02 help:active-profiles

那么配置文件就会被激活,所以显然我没有拼写任何错误。

我是不是忽略了什么?还有其他方法可以使这项工作有效吗?

我发现存在类似的问题: Can I make one maven profile activate另一个?
然而,恕我直言,这不是重复的 - 我发现我的方法不起作用,我想了解原因。 (我已阅读参考资料,但我可能忽略了一些明显的事情)。

I have a multimodule Maven2 project which builds a web application. The application is connected to a backend server and a DB. There are several server instances deployed in our environment, and there are also multiple backend and DB instances for development, UAT, production, etc. So practically, each application configuration needs these 3 coordinates:

  • front-end server
  • back-end server
  • DB

I am working on unifying and automating the application configuration. It is easy and obvious to represent these different configurations as profiles in Maven. Then I can create a specific configuration by activating one profile from each group, e.g.

mvn -Pserver.Server1,backend.prod,db.uat clean install

This is a bit tedious to type and error-prone - if a specific server is misconfigured to connect to the wrong DB, the price can be high. One obvious way to fix this would be to put all useful profile combinations into script files.

But I thought I could be more clever than that by activating the necessary back-end and DB profile directly from the server profile. The server profiles are in the main pom, e.g.

<profile>
    <id>server.myserver</id>
    <properties>
        <jboss.home>D:\Programs\jboss-4.2.1.GA</jboss.home>
        <server.name>NightlyBuild</server.name>
        <hosttobind>192.168.1.100</hosttobind>
        <servlet.port>8080</servlet.port>
        ...
        <db>dev02</db>
    </properties>
</profile>

And the backend and DB profiles are in the pom of the Config submodule, e.g.

<profile>
    <id>db.dev02</id>
    <activation>
        <property>
            <name>db</name>
            <value>dev02</value>
        </property>
    </activation>
    <properties>
        <jdbc.address>jdbc:oracle:thin:@192.168.0.101:1521:dbdev02</jdbc.address>
    </properties>
</profile>

So in theory, since the server.myserver profile sets the db property to dev02, this should trigger the activation of the db.dev02 profile in the child pom. However, this does not happen. (Nor if the two profiles are in the same pom, btw). If I set the property from the command line with

mvn -Ddb=dev02 help:active-profiles

then the profile is activated though, so apparently I haven't misspelled anything.

Have I overlooked something? Is there any other way to make this work?

I see that there exists a similar question: Can I make one maven profile activate another?
However, IMHO this is not a duplicate - I see that my approach is not working and I would like to understand why. (I have read the reference, but I might have overlooked something obvious).

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

╭ゆ眷念 2024-08-28 23:15:36

该功能根本不存在。属性激活器使用传入的属性,而不是配置文件设置的任何内容(否则,如果没有一些更复杂的逻辑,它就不知道以什么顺序激活它们)。

您使用的解决方案具有相同的属性来激活您想要一起做的事情,这是最好的解决方案。我意识到这可能并不总是令人满意 - 在这种情况下,您所能做的就是退回到使各个配置文件尽可能简单,以便您可以在命令行上以您想要的方式组合它们,而无需在它们之间重复内容。

涵盖此功能的问题是:https://issues.apache.org/jira/browse/ MNG-3309
涉及属性激活的问题是:https://issues.apache.org/jira/browse /MNG-2276

The feature simply doesn't exist. The property activator uses the incoming properties, not anything set by the profiles (as otherwise it wouldn't know what order to activate them in without some more complex logic).

The solution you used, of have identical properties to activate the things you want to do together, is the best solution. I realise that may not always be satisfactory - in that case all you can do is fall back to making the individual profiles as simple as possible so that you can combine them in the ways you want on the command line, without duplicating things across them.

The issue covering this feature is: https://issues.apache.org/jira/browse/MNG-3309
The issue covering the property activation is: https://issues.apache.org/jira/browse/MNG-2276

开始看清了 2024-08-28 23:15:36

Brett 提到的 Issue MNG-2276 已在 maven 3.x 中解决,所以您现在允许在 settings.xml 中定义属性以触发 pom 中的配置文件。下面是一个示例:

在 settings.xml 中:

<profile>
    <id>localDist</id>
    <activation>
        <property><name>localDist</name></property>
    </activation>
    <properties>
        <doReleaseTasks>true</doReleaseTasks>
    </properties>
</profile>

在您的 pom 中(或者更好的是,在您的父 pom 中):

<profile>
    <id>doReleaseTasks</id>
    <activation>
        <property><name>doReleaseTasks</name></property>
    </activation>
    <build>
        <plugins>
            ... mvn -DlocalDist will activate these plugins
        </plugins>
    </build>
</profile>

使用 enforcer 插件强制使用 mvn 3.0 或更高版本是个好主意:

<build>
    <plugins>
        <plugin>
            <artifactId>maven-enforcer-plugin</artifactId>
            <executions>
                <execution>
                    <id>enforce-maven</id>
                    <goals> <goal>enforce</goal> </goals>
                    <configuration>
                        <rules>
                            <requireMavenVersion>
                                <version>[3.0,)</version>
                                <message>
*** Maven 3.x required to allow cascading profiles to be activated in settings.xml (MNG-2276)
                                </message>
                            </requireMavenVersion>
                        </rules>
                    </configuration>
                </execution>
            </executions>
        </plugin>
    </plugins>
</build>

Issue MNG-2276 mentioned by Brett was resolved in maven 3.x, so you are now allowed to define properties in settings.xml to trigger profiles in your pom. Here is an example:

In settings.xml:

<profile>
    <id>localDist</id>
    <activation>
        <property><name>localDist</name></property>
    </activation>
    <properties>
        <doReleaseTasks>true</doReleaseTasks>
    </properties>
</profile>

In your pom (or better yet, in your parent pom):

<profile>
    <id>doReleaseTasks</id>
    <activation>
        <property><name>doReleaseTasks</name></property>
    </activation>
    <build>
        <plugins>
            ... mvn -DlocalDist will activate these plugins
        </plugins>
    </build>
</profile>

Good idea to use enforcer plugin to force mvn 3.0 or greater:

<build>
    <plugins>
        <plugin>
            <artifactId>maven-enforcer-plugin</artifactId>
            <executions>
                <execution>
                    <id>enforce-maven</id>
                    <goals> <goal>enforce</goal> </goals>
                    <configuration>
                        <rules>
                            <requireMavenVersion>
                                <version>[3.0,)</version>
                                <message>
*** Maven 3.x required to allow cascading profiles to be activated in settings.xml (MNG-2276)
                                </message>
                            </requireMavenVersion>
                        </rules>
                    </configuration>
                </execution>
            </executions>
        </plugin>
    </plugins>
</build>
世俗缘 2024-08-28 23:15:36

虽然这可能不是这个特定问题的直接答案,但我有一个类似的情况,我需要以级联方式配置多个配置文件。
最初,我有一个名为 qulice 的配置文件,它使用了一个过时的依赖项,并且无法与最新的 Java 版本一起使用。我需要根据安装的JDK选择依赖版本。实现此目的的唯一方法是使用多个 Maven 配置文件。但是,我想维护单一配置文件以避免 CI/CD 出现问题。
换句话说,我需要添加 quliceJava8quliceJava11 配置文件,同时保留 qulice 配置文件,这将触发 quliceJava8基于 JDK 版本的 code> 或 qliceJava11 配置文件。
我通过使用以下配置找到了解决方法:

<profiles>
  <profile>
    <id>qulice</id>
    <build>
      <plugins>
        <plugin>
          <groupId>com.qulice</groupId>
          <artifactId>qulice-maven-plugin</artifactId>
          <version>${qulice.version}</version>
        </plugin>
      </plugins>
    </build>
  </profile>
  <profile>
    <id>quliceJava11</id>
    <activation>
      <jdk>[11,)</jdk>
    </activation>
    <properties>
      <qulice.version>0.22.0</qulice.version>
    </properties>
  </profile>
  <profile>
    <id>quliceJava8</id>
    <activation>
      <jdk>1.8</jdk>
    </activation>
    <properties>
      <qulice.version>0.21.0</qulice.version>
    </properties>
  </profile>
</profiles>

虽然您没有在此处以级联方式激活配置文件,但您可以通过这种方式配置它们。现在我可以打电话了:

mvn install -Pqulice 

一切正常。

Although this might not be a direct answer to this specific question, I had a similar case where I needed to configure several profiles in a cascaded manner.
Originally, I had a single profile called qulice that used a dependency which became outdated and didn't work with the latest Java versions. I needed to choose the dependency version based on the JDK installed. The only way to implement this was by using multiple Maven profiles. However, I wanted to maintain a single profile to avoid issues with CI/CD.
In other words, I needed to add quliceJava8 and quliceJava11 profiles while preserving the qulice profile, which would trigger either the quliceJava8 or quliceJava11 profiles based on the JDK version.
I found the workaround solution by using the following configuration:

<profiles>
  <profile>
    <id>qulice</id>
    <build>
      <plugins>
        <plugin>
          <groupId>com.qulice</groupId>
          <artifactId>qulice-maven-plugin</artifactId>
          <version>${qulice.version}</version>
        </plugin>
      </plugins>
    </build>
  </profile>
  <profile>
    <id>quliceJava11</id>
    <activation>
      <jdk>[11,)</jdk>
    </activation>
    <properties>
      <qulice.version>0.22.0</qulice.version>
    </properties>
  </profile>
  <profile>
    <id>quliceJava8</id>
    <activation>
      <jdk>1.8</jdk>
    </activation>
    <properties>
      <qulice.version>0.21.0</qulice.version>
    </properties>
  </profile>
</profiles>

Although you don't activate profiles in a cascaded manner here, you can configure them this way. Now I can call:

mvn install -Pqulice 

And everything works fine.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文