Gradle使用不同的属性文件构建多个.war文件[关闭]

Posted 2023-02-27

【中文标题】Gradle使用不同的属性文件构建多个.war文件[关闭]

【英文标题】：Gradle build multiple .war files with different properties file [closed]

【发布时间】：2015-11-18 14:58:29

【问题描述】：

我们正在使用 Spring Boot 和相关依赖项从头开始开发一个新的 Web 应用程序，并使用 Gradle 构建。

我们的项目有近 5 个测试阶段，每个阶段在不同的服务器上执行，因此最终在每台服务器上的配置略有不同。

上述场景是一种非常常见的情况，通常我在早期项目中遵循的做法是将“属性”文件直接保存在服务器的类路径下，这样同一个 .war 文件就可以部署在多个服务器上并且仍然根据服务器/环境有不同的配置。

现在，上述设置的明显缺点是 - 这样的设置不能通过某些版本控制器轻松地与其他开发人员共享。此外，我无法使用 Gradle 中“处理资源”任务的强大功能在构建过程中引入一些动态属性。

现在，如果我在项目设置中拉取 .properties 文件，那么我可以轻松地对其进行版本控制，共享变得更容易，并且我还可以通过 Gradle 引入动态属性。缺点是更新 .properties 文件后可能需要准备多个 .war 文件。

我有两个问题？

您对上述两种方式有何看法？鉴于这种情况，您会选择什么以及为什么（处理这种情况的任何其他方式）？ 在构建多个.war文件的第二种情况下，如何重新运行war任务以生成新的输出文件？

谢谢！

【参考方案1】：

您应该为所有环境构建一场战争。为每个环境设置一个操作系统环境变量（例如 spring.profile=dev、spring.profile=prod）。

根据该 envvar 读取正确的属性文件（spring 将为您执行此操作）。 Ex application-dev.properties, application-prod.properties

在环境变量中存储生产数据库连接密码。

见

http://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-external-config.html

【讨论】：

我就是这么做的。因为 99% 的属性是相同的，所以我必须将我的所有属性都推送到 appliation.properties 中。然后因为我只能从 application.properties 控制活动配置文件，所以我在同一个文件中也有变量部分（spring.profile）。因此，我最终得到了上面描述的 2 个场景..

@FirstX “控制活动配置文件”是什么意思？您没有在属性文件中设置活动配置文件，而是在 OS env var 中设置它。此外，您可以拥有多个属性文件

【参考方案2】：

当然，可以将所有属性文件滚动到战争中并构建一些“配置文件”逻辑，因为您使用的是 Spring，您实际上可能有这个。 Spring does support "profiles" 基于系统级属性的值。

我过去使用的另一种方法是在构建时“构建”属性文件。我已经用 Gradle 做到了这一点。本质上，您有一个运行时属性文件“模板”，其中包含每个环境特定属性的占位符和一个属性的属性文件，有条件地拉入您的 Gradle 项目并由 Gradle 复制任务中的“扩展”方法使用。您可以使用-Penv=PROD 之类的命令行属性来定位您的环境。

你的战争任务可能依赖于另一个任务，buildRuntimeProperties 或其他什么。这将构建环境特定的属性。此时您必须决定如何处理您的构建工件：

将属性文件构建到战争中，并将每个特定于环境的战争发布到带有识别版本或工件 ID 的工件存储库中 单独管理属性文件并保持战争环境不可知，并使用您的属性解析代码来查找战争之外的属性。

【讨论】：

你能提供任何代码sn-p或链接吗？我想遵循第二种方法，但不知道该怎么做。