Preface
Pain points:
In the process of Java development, we often have to face various environments, such as development environment, test environment, and formal environment, and these environments have different requirements for projects.
Before this, we often need to manually modify the corresponding configuration file and then type it into war before we can deploy it to the corresponding environment.
However, this can easily cause problems, because it is easy to cause less or miss changes, causing unnecessary trouble
fantasy:
How happy it would be if there was something that allowed us to specify a parameter when we type war and automatically compile the project into the war in the corresponding environment! ! !
The result: There is really such a thing, that is maven-profile
During the development process, we often configure different parameters according to different environments, such as the ip, username, password, url, secret key, etc. of the data source will be different. The traditional method is to modify the parameter values in the properties file or comment and comment in a configuration file. This is not only prone to errors, but also waste unnecessary time. More importantly, publishing the code to the test environment or production environment is easy to forget to modify. To solve this problem, maven provides a solution, which is profile.
The following picture is a traditional way, and needs round-trip comments and explanations
Location defined by profile
Implementation of filter method
Step 1: Define the three files of application-dev.properties, application-test.properties, and application-pro.properties respectively.
application-dev.properties
env.jdbc.username=devenv.jdbc.password=123456
application-test.properties
env.jdbc.username=testenv.jdbc.password=888888
application-pro.properties
env.jdbc.username=rootenv.jdbc.password=666666
Step 2: Define the total property file application.properties, and the value in this file refers to the key in application-<env>.properties.
application.properties
// Reference keyjdbc.username=${env.jdbc.username}jdbc.password=${env.jdbc.password}# Public configuration salt=123456789 Step 3: Configure profile
<profiles> <profile> <!-- Development environment --> <id>dev</id> <properties> <env>dev</env> </properties> <activation> <!-- Set default activation of this configuration --> <activeByDefault>true</activeByDefault> </activation> </profile> <profile> <!-- Test environment --> <id>test</id> <properties> <env>test</env> </properties> </properties> </profile> <profile> <!-- Release environment --> <id>pro</id> <properties> <env>pro</env> </properties> </profile> </profile> </profile> </profile> <profile> <!-- Release environment --> <id>pro</id> <properties> <env>pro</env> </properties> </profile> </profile> </profiles>
Step 4: Configure filter and resource
${env} is the name of mvn package -P <env> , which tells the key applied in application.properties is the key of the property file.
<build> <finalName>profile-app</finalName> <!-- Define the address of the variable configuration file --> <filters> <filter>src/main/resources/config/application/application-${env}.properties</filter> </filters> <resources> <resource> <directory>src/main/resources</directory> <filtering>true</filtering> </resources> </resources> <plugins> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-war-plugin</artifactId> </plugin> </plugins> </build> Package and run
// If the environment is not specified, the default is an environment with activeByDefault=true. Currently, it refers to the development environment mvn package// The environment specified in the package passes the -P parameter, note that p is capitalized mvn package -P <env>
From the result of running mvn packege -P test, you can see that jdbc.username and jdbc.password in classes/application.perperties in generated target directory are the values of env.jdbc.username and env.jdbc.password configured in application-test.properties.
If you want to use the attribute configuration file in spring, just introduce this total configuration file directly, and the mission of other environment configuration files has ended.
<context:property-placeholder location="classpath:application.properties"/>
Implementation principle:
Define different profiles for each different environment in pom.xml. Each profile has an environment name. Then define different configuration files for different environments (such as application-<env>.properties ), and then define a total property file (such as application.properties). Then let the value of application.properties reference the corresponding key in application-<env>.properties , and specify the name of the environment to be packaged when packaging. In this way, the value of the key in application.properties is the corresponding value of the environment application-<env>.properties.
Multi-resource implementation method
step
Step 1: Create an env directory in src/main/resource, then create a subdirectory of each environment, and then create a file named config.properties under each environment subdirectory. Each key is the same and the value is different.
env/dev/config.properties
jdbc.username=devjdbc.password=123456
env/test/config.properties
jdbc.username=testjdbc.password=888888
env/pro/config.properties
jdbc.username=rootjdbc.password=666666
Step 2: Create an environment-independent application.properties
application.properties
# Public configuration salt=123456789
Step 3: Configure profiles
<profiles> <profile> <!-- Development environment --> <id>dev</id> <properties> <env>dev</env> </properties> <activation> <!-- Set default activation of this configuration --> <activeByDefault>true</activeByDefault> </activation> </profile> <profile> <!-- Test environment --> <id>test</id> <properties> <env>test</env> </properties> </properties> </profile> <profile> <!-- Release environment --> <id>pro</id> <properties> <env>pro</env> </properties> </properties> </profile> <profile> <!-- Release environment --> <id>pro</id> <properties> <env>pro</env> </properties> </profile></profiles>
Step 4: Configure resource
<build> <finalName>profile-app</finalName> <!-- Define the address of the variable configuration file --> <resources> <resource> <directory>src/main/resources</directory> <excludes> <exclude>env/dev/*</exclude> <exclude>env/test/*</exclude> <exclude>env/pro/*</exclude> </excludes> <filtering>true</filtering> </resource> <resource> <directory>src/main/resources/env/${env}</directory> <includes> <include>*.*</include> <include>**/*.xml</include> <include>**/*.properties</include> </includes> <filtering>true</filtering> </resource> </resources> <plugins> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-war-plugin</artifactId> </plugin> </plugin> </plugins></build> Step 5: Run mvn package -P test
If you often use mvn package -P <env> you can configure some maven in idea. The steps are: Edit Configurations… ― + ―- Maven ―- Add maven commands for each environment. In the future, double-click any of Run Configurations, which is equivalent to running mvn package -P <env> command.
Comparison of the two ways
The filter method will pack all application-dev.properties, application-test.properties, and application-pro.properties files, and this method can only be used for property files. If there are other files (such as .xml) and have different configurations according to different environments, this method is difficult to deal with.
When packaging, the multi-resource method only packages the configuration files of the specified environment. You can place various files into their respective environment folders, and the entire folder will be packaged in when packaging. Recommend this method
Summarize
The above is the entire content of this article. I hope that the content of this article has certain reference value for everyone's study or work. If you have any questions, you can leave a message to communicate. Thank you for your support to Wulin.com.