Minimum Configuration Solution Guide for Multi-environment Construction of Maven Project

Time:2019-9-11

Read the original text directly like E: https://maven.apache.org/guid…

Building the same project for different environments is always a hassle. You may have test and production servers, or you may have a set of servers running the same application, but with different configuration parameters. This guide is intended for useside(profiles) to package the project in the specified environment. You can refer to the introduction of Profile concepts for more information.

Tips:

This guide assumes that you have a basic understanding of Maven 2. There will be a brief introduction to maven settings. Simply refers to the fact that only a few files in your project configuration change depending on the environment. There are other better solutions when two-dimensional or even multi-dimensional configuration changes.
This example uses a standard directory structure:

pom.xml
src/
  main/
    java/
    resources/
  test/
    java/

There are three files under src/main/resources:

  • Environment. properties – This is the default configuration and will be packaged in the final release package.
  • Environment. test. properties – This is the configuration for testing.
  • Environment. prod. properties – This is a configuration similar to the test solution for the production environment.

In the project descriptor, you need to configure different profiles. The profiles for the tests listed here only.

 <profiles>
   <profile>
     <id>test</id>
     <build>
       <plugins>
         <plugin>
           <artifactId>maven-antrun-plugin</artifactId>
           <executions>
             <execution>
               <phase>test</phase>
               <goals>
                 <goal>run</goal>
               </goals>
               <configuration>
                 <tasks>
                   <delete file="${project.build.outputDirectory}/environment.properties"/>
                   <copy file="src/main/resources/environment.test.properties"
                         tofile="${project.build.outputDirectory}/environment.properties"/>
                 </tasks>
               </configuration>
             </execution>
           </executions>
         </plugin>
         <plugin>
           <artifactId>maven-surefire-plugin</artifactId>
           <configuration>
             <skip>true</skip>
           </configuration>
         </plugin>
         <plugin>
           <artifactId>maven-jar-plugin</artifactId>
           <executions>
             <execution>
               <phase>package</phase>
               <goals>
                 <goal>jar</goal>
               </goals>
               <configuration>
                 <classifier>test</classifier>
               </configuration>
             </execution>
           </executions>
         </plugin>
       </plugins>
     </build>
   </profile>

   .. Other profiles go here ..

 </profiles>

There are three things configured in this code:

  1. The antrun plug-in is configured to run in the test phase and will be copiedenvironment.test.propertiesFile toenvironment.properties.
  2. The test plug-in is configured to skip all tests when compiling and generating test packages. This may be useful to you because you may not want to test the production environment.
  3. JAR plug-ins are configured to create JAR packages with test modifier identifiers.

The way to activate the profile is mvn -Ptest installIn addition to the normal steps, the steps defined in Profile will be executed. You will get two packages, “foo-1.0.jar” and “foo-1.0-test.jar”. The two packages are the same.

Look out:

Maven 2 can’t just weave packages with modifiers. (i.e. He has to generate them.)mainPack) So they are the same. JAR plug-ins need to be improved. It would be better to catalogue them in different catalogues.
The use of deletion tasks seems a bit weird, just to ensure that files can be copied. The copy task looks at the timestamp of the source and target files and only copies different files from the previous one.
The compiled configuration file will be in target/classes, and it will not be overwritten, because the resources plug-in uses the same timestamp checking, so it is always cleaned up when building this profile.

So force you to build a single package for a single environment each time you build it. Then “mvn clean” if you change the profile option parameter. Otherwise, you will mix the configuration of different environments together.

Literature:

Introduction to Side Construction
Standard catalogue structure

Recommended Today

Hadoop MapReduce Spark Configuration Item

Scope of application The configuration items covered in this article are mainly for Hadoop 2.x and Spark 2.x. MapReduce Official documents https://hadoop.apache.org/doc…Lower left corner: mapred-default.xml Examples of configuration items name value description mapreduce.job.reduce.slowstart.completedmaps 0.05 Resource requests for Reduce Task will not be made until the percentage of Map Task completed reaches that value. mapreduce.output.fileoutputformat.compress false […]