Multi environment construction of Maven basic course

Time:2019-11-14

This is another series, a series to tell Maven through. I hope it can help you!

Preface

The multi environment construction summarized in this article is absolutely the content that will be used in the actual work. For example, the Maven project of my current company basically uses the multi environment construction that this article will summarize. So what exactly is multi environment construction?

Let’s imagine a scene like this. Generally, our projects will have development environment, test environment and production environment. The configuration of databases in these environments is basically different, so we need to be able to identify the environment and use the correct configuration data when building the project. How can we use different configuration data flexibly for multiple environments?

In maven, in order to support this scenario flexibly, there are three built-in features, namely attribute, profile and resource filtering. We will elaborate on these three features through specific code examples.

Maven attribute

For Maven attribute, we have also touched on it in the previous article, for example, it was used as follows:

<project>
    <modelVersion>4.0.0</modelVersion>
    <groupId>com.jellythink.BookStore</groupId>
    <artifactId>project-A</artifactId>
    <version>1.0.0</version>

    <properties>
        <springframework.version>5.1.6.RELEASE</springframework.version>
    </properties>
    <dependencies>
        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-core</artifactId>
            <version>${springframework.version}</version>
        </dependency>
    </dependencies>
</project>

adopt<properties>Element, we can customize one or more Maven attributes and use them elsewhere in POM${property name}The greatest significance of this method is to eliminate the duplication and facilitate the later unified modification. But this is not all of Maven attributes. In fact, there are six types of attributes in Maven:

  • Built-in attributes
    There are two common built-in attributes:

    • ${basedir}Represents the project root, which is the directory containing the pom.xml file
    • ${version}Indicates project version
  • POM attribute
    We can use the POM attribute to reference the value of the corresponding element in the POM file, for example${project.artifactId}It corresponds.<project><artifactId>The value of the element. Common POM attributes include:

    • ${project.build.sourceDirectory}: the main source directory of the project. The default issrc/main/java/
    • ${project.build.testSourceDirectory}: the test source directory of the project. The default issrc/test/java/
    • ${project.build.directory}: project build output directory, default istarget/
    • ${project.outputDirectory}: project main code compilation output directory, default istarget/classes/
    • ${project.testOutputDirectory}: project test code compilation output directory, default totarget/test-classes/
    • ${project.groupId}: groupid of the project
    • ${project.artifactId}: artifactid of the article
    • ${project.version}: version of the project, and${version}equivalence
    • ${project.build.finalName}: the name of the project packaging output file. The default is${project.artifactId}-${project.version}
These attributes correspond to a POM element. Some default values of attributes are defined in super POM.
  • Custom properties
    Custom properties are defined by<properties>The attributes defined by elements are very clear in the first example.
  • Settings property
    Do you remember the settings.xml file in Maven? If you don’t remember, you can go to this “installation and configuration of Maven basic tutorial”. The settings property indicates that we can use thesettings.The first attribute refers to the value of the XML element in the settings.xml file. For example, we can use${settings.localRepository}To reference the address of the user’s local warehouse.
  • Java system properties
    All Java system properties can be referenced using Maven properties, such as${user.home}Directory pointing to the user. We can usemvn help:systemView all Java system properties.
  • Environment variable properties
    All environment variables can be used toenv.The Maven attribute reference at the beginning. such as${env.JAVA_HOME}Points to the value of the Java home environment variable. We can usemvn help:systemView all Java system properties.

Using these Maven attributes correctly can help us simplify the configuration and maintenance of POM.

Resource filtering

In our development process, we often encounter such configuration files:

database.jdbc.driverClass = com.mysql.jdbc.driverClass
database.jdbc.connectionURL = jdbc:mysql://localhost:3306/dev
database.jdbc.username = develop
database.jdbc.password = develop-password

The above configuration data is only for the developers. If the testers do it, they will use a set of configuration files as follows:

database.jdbc.driverClass = com.mysql.jdbc.driverClass
database.jdbc.connectionURL = jdbc:mysql://localhost:3306/test
database.jdbc.username = test
database.jdbc.password = test-password

That is to say, in the development environment and test environment, we need to use different configuration files. Before we use maven, we manually modify the corresponding configuration data. Then again, it’s very troublesome and easy to make mistakes. Now with maven, we need to make a change.

In order to cope with different use environments, we need to replace the changed part of the configuration file with Maven attribute. For example, the above configuration file needs to be modified to look like this:

database.jdbc.driverClass = ${db.driver}
database.jdbc.connectionURL = ${db.url}
database.jdbc.username = ${db.username}
database.jdbc.password = ${db.password}

We define four Maven properties in the configuration file: db.driver, db.url, db.username and db.password. Next, we need to define these properties somewhere. In maven, we only need to use one extraprofileTo define these properties.

<profiles>
    <profile>
        <id>dev</id>
        <properties>
            <db.driver>com.mysql.jdbc.driverClass</db.driver>
            <db.url>jdbc:mysql://localhost:3306/dev</db.url>
            <db.username>develop</db.username>
            <db.password>develop-password</db.password>
        </properties>
    </profile>
</profiles>

Passed hereprofileWe define these attributes and use a value with ID of dev to distinguish this profile. In this way, we can define different profiles for different environments in the future, which is very flexible.

With the attribute definition, these attributes are also used in the configuration file. Is this OK? It’s not that simple! As we all know, the Maven attribute is only parsed in POM by default. in other words,${db.username}Put it into POM, it will be resolved to develop, but if put it into a file in Src / main / resources / directory, it will still be ${dB. Username} when it is built. So we need to have Maven parse the Maven attribute in the resource file.

The processing of resource files is actuallymaven-resources-pluginBut its default behavior is to copy the project main resource file to the main code compilation output directory and the test resource file to the test code compilation output directory. We just need to turn on resource filtering, and this plug-in can parse Maven attribute in resource file.

Enable filtering for the main resource directory:

<build>
    <! -- enable filtering for main resource directory -- >
    <resources>
        <resource>
            <directory>${project.basedir}/src/main/resources</directory>
            <filtering>true</filtering>
        </resource>
    </resources>
    
    <! -- enable filtering for test resource directory -- >
    <testResources>
        <testResource>
            <directory>${project.basedir}/src/main/resources</directory>
            <filtering>true</filtering>
        </testResource>
    </testResources>
</build>

We passedmvn clean package -PdevCommand to build. among-PParameter to activate a profile on the command line. I didn’t understand the profile. It doesn’t matter. Let’s talk about it in detail. After the construction, the database configuration in the output directory is the configuration of the development environment:

database.jdbc.driverClass = com.mysql.jdbc.driverClass
database.jdbc.connectionURL = jdbc:mysql://localhost:3306/dev
database.jdbc.username = develop
database.jdbc.password = develop-password

Maven Profile

When it comes to profile, you may be confused about profile. Here is a detailed summary of profile. Profile is a very useful feature, at least in our company’s projects. Profile is customized for seamless migration in different environments. We can configure different profiles in different environments, such as the development environment and test environment mentioned above. We can configure profiles through profiles:

<profiles>
    <profile>
        <id>dev</id>
        <properties>
            <db.driver>com.mysql.jdbc.driverClass</db.driver>
            <db.url>jdbc:mysql://localhost:3306/dev</db.url>
            <db.username>develop</db.username>
            <db.password>develop-password</db.password>
        </properties>
    </profile>
    <profile>
        <id>test</id>
        <properties>
            <db.driver>com.mysql.jdbc.driverClass</db.driver>
            <db.url>jdbc:mysql://localhost:3306/test</db.url>
            <db.username>test</db.username>
            <db.password>test-password</db.password>
        </properties>
    </profile>
</profiles>

As you can see, the values of the same property in the two profiles are different; similarly, we can add more profile configurations, such as production configurations. Next, we can use the-PdevActivate dev profile using-PtestActivate test profile.

summary

About Maven’s multi environment construction, this article basically summarizes all kinds of grammars I met in my work, and these usages are also representative. I hope that through my summary here, it will help you. In the future work, you will not be unfamiliar with this kind of grammar. I also hope that you can use these usages in building your own projects To improve their work efficiency.

Jelly think, play code, play technology!

May 5, 2019, Hohhot, Inner Mongolia.


Multi environment construction of Maven basic course