A brief introduction to profiles application in Maven

In the development process, our software will face different operating environments, such as the development environment, test environment, production environment, and our software in different environments, some configuration may not be the same, such as data source configuration, log file configuration, as well as some basic configuration of software running process, Every time we deploy the software to a different environment, we need to modify the corresponding configuration file, so that the change back and forth, is a very troublesome thing. Is there a way that we can publish to different environments without having to modify the configuration? Of course, that's the next thing to do.

Of course, the premise here is to use Maven as a build tool.

Using MAVEN to build portability for multiple environments requires the profile capabilities provided by Maven to activate different profiles through different environments to achieve the portability of the build.

First, configure profile

The first is the profile configuration, which adds the following profiles in Pom.xml: [HTML] view plain copy

<profiles> <profile> <id>local</id> <build> <filters> <filter>profiles/config-local.properties</filter> </filters> &lt
                    ;resources> <resource> <filtering>true</filtering> <directory>src/main/resources</directory> </resource> &LT;/RESOURCES&G
        T
            </build> </profile> <profile> <id>test</id> <build> <filters> <filter>profiles/config-test.properties</filter> </filters&gt
            ;
                    <resources> <resource> <filtering>true</filtering> <directory>src/main/resources</directory> </resource> &LT;/RESOURCes> </build> </profile> <profile> <id>product</id> <bu
            Ild> <filters> <filter>profiles/config-production.properties</filter> </filters> <resources> <resource> <filtering >true</filtering> <directory>src/main/resources</directory> </ resource> </resources> </build> </profile> </profiles>

There are three environments defined, namely development (development environment), test (testing environment), production (production environment), where the development environment is activated by default (Activebydefault is True), This defaults to the development environment if you do not specify a profile.

Each profile also defines two properties, where profiles.active represents the name of the activated profile, and Deploy.url represents the address of the publisher. We need to use these two properties below.

In addition, host and Port are the Publisher address and port number, respectively.

Second, the configuration file for different environments, we define different configuration files, and these configuration files as resource files into the resources directory of the MAVEN project, namely the Src/main/resources directory, and the configuration of each environment is placed in the corresponding directory, And all the environments are common configuration, put directly in the Src/main/resources directory. As shown in the following illustration:

As shown in the figure, the development environment, test environment, production environment configuration files are placed in the Src/main/resources directory, development, test, production three sub-directories, Configuration files that are common to all environments are spring-applicationcontext.xml directly into the Src/main/resources directory. Where jdbc.properties configures the data source, logback.xml configuration log.

Third, the MAVEN resource plug-in is configured under the Build node in the POM, configuring the location of the resource file as follows:
[HTML] View plain copy <build>       <resources>            <resource>                <directory>src/main/resources</directory>                <!--  Resource root to exclude configuration for each environment, use a separate resource directory to specify  -->                <excludes>                    < exclude>test/*</exclude>                    <exclude>production/*</exclude>                    <exclude>development/*< /exclude>              </excludes>            </resource>            <resource>                <directory>src/main/resources/${profiles.active}</directory>            </resource>       </resources>    </build>  

First, the first resource file location src/main/resources need to queue up each environment configuration file, the configuration of each environment we in the second <resource> node is specified by the Profiles.active property previously configured in profile. That is, src/main/resources/${profiles.active}. This allows the configuration file under the specified directory to be loaded when the specified profile is activated, for example, the resource directory is src/main/resources/production, which is currently active for production profiles. This achieves the purpose of loading different configurations for different environments.

Iv. Configuring the Tomcat-maven-plugin plugin [HTML] view plain copy <plugin> <groupid>org.codehaus.mojo</groupi       D> <artifactId>tomcat-maven-plugin</artifactId> <version>1.2-SNAPSHOT</version>           <configuration> <url>${deploy.url}</url> <server>tomcat</server> <path>/appcontext</path> </configuration> </plugin>

The <url> node that is published is the Deploy.url attribute configured in the previous profile, so that different environments specify different publishing addresses. The <server> and <path> nodes are the user-configured ID of the publisher and the context name of the app.

V. Build or publish

All the required configurations are complete, and here's the time to witness the miracle. You can build a war package or publish it to a different environment by specifying a different profile when you run the MAVEN command. Such as:

MVN clean package-pproduction to build a war package that is needed for the production environment

MVN Tomcat:redeploy-ptest is released to the test environment

Since the default profile is development, if we do not specify profiles, then loading is the configuration file under the development environment deployment. That is, when we develop tests locally, we don't have to worry about profile issues.

Also, there is no need for additional configuration when using the Tomcat plugin for hot deployment in eclipse at local development time. Real to do the different environments to automatically switch, can be ported to build.

In addition, using Hudson to integrate Maven is also very convenient for continuous integration.