1. Spring Profile

Spring can use Profile absolutes to perform in different environments, including configuration, loading beans, dependencies, and so on. Spring’s general Profile projects include dev(development), Test (unit testing), QA (integration testing), and PROD (production environment). The profile enabled by the spring.profiles. Active property. The SpringBoot configuration file defaults to application.properties(or yaml, otherwise only properties is specified). Profiles under different profiles are managed by application-{Profile}. Properties, and independent Profile profiles overwrite the properties under the default file.

2. Maven Profile

Maven also has Profile Settings that allow you to perform different operations, including configuration, dependencies, behavior, and so on, for different Profile environments during the build process. Maven’s Profile is managed by the tag of POM.xml. You can set the following parameters in each Profile: ID, properties, activation, dependencies, etc. This article doesn’t say much about Spring and Maven profiles, but check them out for details.

Maven manages Spring profiles

Since the build is based on Maven(or Gradle, only Maven is described here). So using Maven to manage Spring build profiles is very convenient. Maven manages Spring profiles in five steps, described below.

3.1 Removing the default Tomcat Dependency

In the SpringBoot MVC project, Tomcat runs inline by default. If special Settings are required or Undertow is used, the default Tomcat dependency needs to be removed:



<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
    <exclusions>
        <exclusion>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-tomcat</artifactId>
        </exclusion>
    </exclusions>
</dependency>Copy the code

If you are using MyBatis, you need to remove the tomcat-JDBC dependency:



<dependency>
    <groupId>org.mybatis.spring.boot</groupId>
    <artifactId>mybatis-spring-boot-starter</artifactId>
    <exclusions>
        <exclusion>
            <groupId>org.apache.tomcat</groupId>
            <artifactId>tomcat-jdbc</artifactId>
        </exclusion>
    </exclusions>
</dependency>Copy the code

3.2 Maven Profile Settings

Under the project’s (if any modules are concrete) POM.xml set:



<! -- Maven control Spring Profile -->
<profiles>
    <profile>
        <id>dev</id>
        <activation>
            <activeByDefault>true</activeByDefault>
        </activation>
        <properties>
            <profileActive>dev</profileActive>
        </properties>
        <dependencies>
            <dependency>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-starter-tomcat</artifactId>
            </dependency>
            <dependency>
                <groupId>org.apache.tomcat</groupId>
                <artifactId>tomcat-jdbc</artifactId>
            </dependency>
        </dependencies>
    </profile>
    <profile>
        <id>prod</id>
        <properties>
            <profileActive>prod</profileActive>
        </properties>
    </profile>
</profiles>Copy the code

As you can see from the above configuration, Maven’s Profile has two configurations: Dev and prod, and dev uses embedded Tomcat, but prod does not, so dev and prod can be run directly (Plugin uses SpringBoot Plugin). Prod cannot be run directly (or deployed under external Tomcat, which is not recommended, as explained below). The profileActive in properties is the declared property, which corresponds to the Spring Profile value.

3.3 Maven Resource Filtering

SpringBoot’s Profile selection needs to be configured in application.properties, and if it is fixed to a file, it needs to be manually modified every time it is packaged, which is cumbersome and error-prone. Maven’s resource filtering feature allows you to modify attributes represented as “@xxx@” at build time. Resource filtering requires configuring resources under the <build> tag of pom.xml:



<! -- Profile operations on resources -->
<resources>
    <resource>
        <directory>src/main/resources</directory>
        <excludes>
            <exclude>application*.properties</exclude>
        </excludes>
    </resource>
    <resource>
        <directory>src/main/resources</directory>
        <! Maven properties = maven properties = maven properties = maven properties = maven properties = maven properties
        <filtering>true</filtering>
        <includes>
            <include>application.properties</include>
            <include>application-${profileActive}.properties</include>
        </includes>
    </resource>
</resources>Copy the code

The first resource above removes all application.properties files under SRC /main/resources. “” is a wildcard, indicating that anything (or nothing) there matches. The second resource adds the application.properties default profile and the corresponding profile profile determined by the profileActive property. And Filtering is true to replace @xx@ with variables in file content (for example, @profileActive in files is replaced with the value of the profileActive attribute).

3.4 Spring Configuring a Profile

In the application.properties default configuration file, configure:



spring.profiles.active              = @profileActive@Copy the code

@profileActive@ indicates that the attribute value will be replaced during Maven build time.

3.5 build

Build command:



mvn clean package -PdevCopy the code

The command above builds the environment package based on Maven Profile dev. If the prod package is needed, replace -p with prod. For convenience I will generate a build.sh file for each project with the following contents:



#! /bin/bash
profileActive=prod
if [ -n "The $1" ]; then
    profileActive=The $1
fi

mvn clean package -Dmaven.test.skip=true -P$profileActiveCopy the code

The script takes one parameter, packaging the corresponding Profile. By default, if no parameter is specified, the PROD environment package is packaged. Note that this command skips the test.

4. To summarize

By completing the above five steps, the project can be packaged to run in different environments depending on your build parameters.

  1. Step 1 removes tomcat and tomcat-JDBC embedded in SpringBoot. This allows us to decide which containers to use to run our projects under what circumstances.
  2. Step 2 configures Maven build Porfile so that the build can distribute different packages according to our instructions.
  3. In step 3, Maven resource filtering is configured, which not only makes resource files under different profiles invisible to each other, but also replaces the attribute values represented by @xx@ in resource files.
  4. Step 4 makes the Spring Profile decision made by Maven so that we don’t have to change the Spring Profile configuration every time we package.
  5. Step 5 shows how to execute build commands under different profiles, and uses a Shell script to make it easy for us to execute builds and skip tests (most of the time we test first when we build projects, we don’t need to test at build time, and the decoupling of testing and build makes us more focused. But at the same time, if you forget pre-testing, you can cause undetected testing problems).

Reference 5.

  • [1]. blog.csdn.net/lihe2008…
  • [2]. blog.csdn.net/hguisu/a…
  • [3]. www.tianmaying.com/tu…
  • [4]. blog.csdn.net/james_wa…
  • [5]. www.jianshu.com/p/755a…