Writing in the front

I believe that those who work in Java will come into contact with Maven at some point. Using Maven to build projects can greatly facilitate the construction of project dependencies. For the Jar packages that need to be depended on in the project, it is simply configured in POM.xml. It can be said that Maven can greatly improve our development efficiency and project maintenance efficiency, can unify the project dependency environment, improve team collaboration efficiency. However, while many people use Maven, how many of them have really mastered the core configuration of Maven?

Project depend on

Project dependencies refer to Maven’s management of project classpath through dependency propagation, dependency priority, optional dependencies, dependency exclusion, dependency scope, and other features.

Dependent propagation characteristic

Our projects often rely on third-party components, which in turn rely on other components. In this case, Maven adds all nodes in the dependency network to the classpath. This is Maven’s dependency propagation feature.

For example, the following configuration

<! -- Add spring MVC dependencies -->
<dependency>
  <groupId>org.springframework</groupId>
  <artifactId>spring-webmvc</artifactId>
  <version>5.2.9. RELEASE</version>
</dependency>
Copy the code

A project that relies directly on Spring-WebMVC is called a direct dependency, while a commons-logging dependency is passed through WebMVC and is called an indirect dependency.

Dependency priority principle

Based on the dependency propagation feature, the whole dependency network will be very complex, and it is inevitable that there will be different versions of the same component. Maven at this point selects one version based on dependency preference.

  • First rule: Shortest path first.
  • Rule 2: In the same path, the first configuration takes precedence.

First Principle Example

<! Commons-logging -->
<dependency>
  <groupId>commons-logging</groupId>
  <artifactId>commons-logging</artifactId>
  <version>1.2</version>
</dependency>
Copy the code

In the example above, Commons-logging relies on 1.1.3 via Spring-webMVC, and on 1.2 directly in the project, which was eventually introduced in version 1.2 based on the shortest path principle.

Example of Principle 2

The main steps are as follows:

(1) Add a new Project B

(2) Configure Project B to rely on Spring-web.3.2.9-release

(3) The current Project directly depends on Project B

After configuration, the current project A has two paths to rely on Spring-Web. The choice of which path depends on the configuration order of WebMVC and Project B.

  • Project A==> Spring-webMVC 5.2.9-release ==> Spring-web 5.2.9-release
  • Project A==> Project B 1.0.snapshot ==> Spring-web.3.2.9-release

Note: in the same POM file, the second principle is not applicable. In the following configuration, the final reference is version 1.2, not version 1.1.1.

<! Add commons-logging before 1.2 -->
<dependency>
 <groupId>commons-logging</groupId>
 <artifactId>commons-logging</artifactId>
 <version>1.1.1</version>
</dependency>

<dependency>
 <groupId>commons-logging</groupId>
 <artifactId>commons-logging</artifactId>
 <version>1.2</version>
</dependency>
Copy the code

Optional dependence

An optional dependency means that the dependency is not required. The default is not optional by adding
true
 to
. Optional dependencies are not passed.

Eliminate dependence on

That is, exclude specified indirect dependencies. Exclusions can be configured to exclude a specified component.

For example, we can use the following configuration to eliminate the dependency on Spring-Web.

<! -- Exclude specified items -->
<exclusions>
  <exclusion>
   <groupId>org.springframework</groupId>
   <artifactId>spring-web</artifactId>
  </exclusion>
</exclusions>
Copy the code

Depend on the range

A component like junit is only needed to run test cases, so there is no need to build the junit.jar package into the package. Maven’s dependency scope configuration
does this. Maven supports four dependency scopes in total:

  • Compile (default): The compile scope depends on both compilation and packaging.
  • Provided: Provides the scope, which is compile-time dependent, but not packaged. Such as: the servlet – API. The jar
  • Runtime: run-time scope, dependent at package time, not compile time. Such as: mysql connector – Java jar
  • Test: Test scope, compile-run test case dependencies, not packaged in. Such as: junit jar
  • The system:The value is specified by the system classpath. Compile-time dependencies are not packaged. Cooperate with<systemPath></systemPath>Use together. Example: Tool.jar under java.home

In addition to importing packages from the system classpath, system can also be used to import third-party jars that are not included in the system by placing them in the project’s lib directory and configuring the relative path. However, since system is not packaged, it needs to be used together with the Maven-dependency plugin. Of course, I still recommend that you manually install third-party jars into the repository.

Here are a few simple usage examples.

  • The common usage of system
<dependency>
     <groupId>com.sun</groupId>
     <artifactId>tools</artifactId>
     <version>${java.version}</version>
     <scope>system</scope>
     <optional>true</optional>
     <systemPath>${java.home}/.. /lib/tools.jar</systemPath>
</dependency>
Copy the code
  • Another way to use system is to introduce the jar directly from the project
<dependency>
  <groupId>jsr</groupId>
  <artifactId>jsr</artifactId>
  <version>3.5</version>
  <scope>system</scope>
  <optional>true</optional>
  <systemPath>${basedir}/lib/jsr305.jar</systemPath>
</dependency>
Copy the code
  • Package the SYSTEM JAR through the plug-in
<plugin>
  <groupId>org.apache.maven.plugins</groupId>\
  <artifactId>maven-dependency-plugin</artifactId>
  <version>2.10</version>
  <executions>
    <execution>
      <id>copy-dependencies</id>
      <phase>compile</phase>
      <goals>
        <goal>copy-dependencies</goal>
      </goals>
      <configuration>
<outputDirectory>${project.build.directory}/${project.build.finalName}/WEB-INF/lib</outputDirectory>
        <includeScope>system</includeScope>
        <excludeGroupIds>com.sun</excludeGroupIds>
      </configuration>
    </execution>
  </executions>
</plugin>
Copy the code
  • Manually add to the local repository
mvn install:install-file -Dfile=mykit-transaction-message.jar -DgroupId=io.mykit -DartifactId=mykit-transaction-message - Dversion = 1.0.0 RELEASE - Dpackaging = jarCopy the code

Project aggregation and inheritance

The aggregation

Aggregation refers to the integration of multiple modules into a unified build, rather than building one by one. Aggregation requires a parent project, which is then configured using
, which corresponds to the relative path of the child project. For example, the following configuration.

<modules>
  <module>mykit-dao</module>
  <module>mykit-service</module>
</modules>
Copy the code

inheritance

Inheritance means that a child project directly inherits attributes, dependencies, and plug-ins from the parent project to avoid repeated configurations. Inheritance can be done in the following ways.

  • Property inheritance
  • Rely on inheritance
  • Plug-in inheritance

Note: the above three configuration subprojects can be overwritten, after overwritten, the subproject will prevail.

Dependency management

Through inheritance characteristics, the child can be indirectly dependent on the parent project, but more child project rely on sometimes do not come, then can be added to the parent project < dependencyManagement > < / dependencyManagement > statement jars, the project need And then it’s introduced into a subproject. For example, the following configuration.

<! Junit 4.12 -->
<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>4.12</version>
    </dependency>
  </dependencies>
</dependencyManagement>
<! -- introduced in subproject -->
<dependency>
  <groupId>junit</groupId>
  <artifactId>junit</artifactId>
</dependency>
Copy the code

The project properties

Using to configure property parameters simplifies configuration. For example, the following configuration.

<! ProName -->
<properties>
  <projectName>projectName</projectName>
</properties>
Copy the code

We can use the following form in the pom.xml file to introduce configured parameters.

${projectName}
Copy the code

Next, let’s look at some of Maven’s default properties, as shown below.

  • ${basedir} project root directory
  • ${version} indicates the project version;
  • The ${project. The basedir} and ${basedir};
  • ${project.version} represents the project version, the same as ${version};
  • ${project.build.directory} Build directory, default target
  • ${project. Build. SourceEncoding} said main source coding format;
  • ${project. Build. SourceDirectory} said main source path;
  • ${project.build.finalName} indicates the output file name;
  • The ${project. Build. OutputDirectory} build process output directory, default is target/classes

Project Build Configuration

Building resource allocation

Basic configuration example:

<defaultGoal>package</defaultGoal>
<directory>${basedir}/target2</directory>
<finalName>${artifactId}-${version}</finalName>
Copy the code

Description:

  • DefaultGoal: the defaultGoal or phase when the build is performed, such as jar:jar or package
  • Directory: The path to the result of the build. Default is ${basedir}/target directory
  • FinalName: The name of the end result of the build, which may be changed in other plugins

Resources configuration example

<resources>
  <resource>
   <directory>src/main/java</directory>
   <includes>
     <include>**/*.MF</include>
     <include>**/*.xml</include>
   </includes>
   <filtering>true</filtering>
  </resource>
  <resource>
   <directory>src/main/resources</directory>
   <includes>
     <include>/ * * *</include>
     <include>*</include>
   </includes>
   <filtering>true</filtering>
  </resource>
 </resources>
Copy the code

Description:

  • Resources: Resource files involved in the build process
  • TargetPath: targetPath of the resource file
  • Directory: The path to the resource file. The default directory is ${basedir}/ SRC /main/resources/
  • Includes: a matching pattern for a set of file names. The matched resource files are processed by the build process
  • Excludes: Matching pattern of a set of file names, and resource files that are matched will be ignored by the build process. Resource files that are also matched by includes and Excludes will be ignored.
  • Filtering: Default false, true indicates that the ${key} parameter in the resource file changes dynamically at compile time. Replace the values in source -dkey and POM or the properties files specified in.

Big welfare

WeChat search the ice technology WeChat 】 the public, focus on the depth of programmers, daily reading of hard dry nuclear technology, the public, reply within [PDF] have I prepared a line companies interview data and my original super hardcore PDF technology document, and I prepared for you more than your resume template (update), I hope everyone can find the right job, Learning is a way of unhappy, sometimes laugh, come on. If you’ve worked your way into the company of your choice, don’t slack off. Career growth is like learning new technology. If lucky, we meet again in the river’s lake!

In addition, I open source each PDF, I will continue to update and maintain, thank you for your long-term support to glacier!!

Write in the last

If you think glacier wrote good, please search and pay attention to “glacier Technology” wechat public number, learn with glacier high concurrency, distributed, micro services, big data, Internet and cloud native technology, “glacier technology” wechat public number updated a large number of technical topics, each technical article is full of dry goods! Many readers have read the articles on the wechat public account of “Glacier Technology” and succeeded in job-hopping to big factories. There are also many readers to achieve a technological leap, become the company’s technical backbone! If you also want to like them to improve their ability to achieve a leap in technical ability, into the big factory, promotion and salary, then pay attention to the “Glacier Technology” wechat public account, update the super core technology every day dry goods, so that you no longer confused about how to improve technical ability!