IDEA配置gradle打包生产环境和测试环境分离

本文前半段摘抄自：https://ixiaozhi.com/java-gradle-archive-different-profile/

后面是自己所写

配置 Gradle 配置文件

build.gradle 中配置相关的 resources 配置文件的目录。不同的资源文件放置在 src/main/filters/$env 目录下，其中 $env 目录为环境名，例如：dev、test、product 等等。且定义了默认环境为 dev 环境。

def env = System.getProperty("profile") ?: "dev"

sourceSets {
    main {
        resources {
            srcDirs = ["src/main/resources", "src/main/filters/$env"]
        }
    }
}

在使用 Gradle 编译的时候，添加参数 -Dprofile=dev 来指定编译的最终代码为何环境。如：

# 把程序编译成生产环境
./gradlew bootRepackage -Dprofile=product

使用 Intellij IDEA 启动不同的Gradle 

环境

A、先新建一个product的gradle Run/Debug Configuratios，然后Tasks注意选择war，经过测试大部分都不行，目前只发现war可以，Script paramters中-Dprofile=product，-D是系统，profile=product是指定为生产环境，与上面的文件夹对应

Gradle支持三种Properties, 这三种Properties的作用域和初始化阶段都不一样，下面分别列出了其部分特点。:

1. System Properties：

   1. 可通过gradle.properties文件，环境变量或命令行-D参数设置 2. 可在setting.gradle或build.gradle中动态修改，在setting.gradle中的修改对buildscript block可见；
   2. 所有工程可见，不建议在build.gradle中修改
   3. 多子工程项目中，子工程的gradle.properties会被忽略掉，只有root工程的gradle.properties有效；

2. Project Properties：

   1. 可通过gradle.properties文件，环境变量或命令行-P参数设置，优先级是:
   2. 可在build.gradle中动态修改，但引用不存在的project properties会立即抛错
   3. 动态修改过的project properties在buildscript block中不可见

3. Project ext properties：

   1. 可在项目的build.gradle中声明和使用，本工程和子工程可见
   2. 不能在setting.gradle中访问

B、然后在tomcat中选择Before launch中加入之前新建的gradle Configuration

C、运行tomcat即可

优化打包：

每次运行gradle进行war打包，并输入参数test

可以看到libs里面的resources的properties里面的配置就会跟着相应改变