Keywords: spring-boot dependency management, spring-boot-dependencies, spring-boot-parent

problem

maven project, dependency management is a very basic and very important function. Now the project is more and more large, more and more dependencies, there are too many two-party packages and three-party packages. Dependency conflict handling is really a headache, often involves many places to adjust.

WeChat Public Number: Escape (Focus on source analysis in the field of java knowledge, understand framework/tool principles from source, validate CS expertise)

Solution

Use a unified dependency management module to manage all dependencies in a project.

Spring-boot projects often use spring-boot-dependencies, spring-boot-starter-parent to manage project dependencies.

The top level project for spring-boot is spring-boot-build. Here's how to get a closer look at the spring-boot dependency solution.

Scheme in spring-boot

spring-boot-build

The top-level project for spring-boot, which specifies maven profiles, maven repositories, Maven plugin Repositories, and Maven build plugin Management.

• profiles: includes code style checking, code style format; easier to import eclipse; maven repository
• repositories: Allows the import of snapshots and milestones BOM during development.This section was deleted by the flatten plug-in during install/deploy.Contains maven central warehouse, spring snapshot warehouse, spring milestone warehouse
• Plugin Repositories: Plug-in repository, including maven central repository, spring snapshot repository, spring milestone repository
• pluginManagement: Build plug-in management, which is configured to store Eclipse m2e settings only and has no effect on the Maven build itself.

spring-boot-dependencies

The parent project of dependencies is spring-boot-build, which contains no code and uses only POM to manage dependencies. pom.xml is as follows:

<parent>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-build</artifactId>
        <version>${revision}</version>
        <relativePath>../..</relativePath>
</parent>
<artifactId>spring-boot-dependencies</artifactId>
<packaging>pom</packaging>
<dependencyManagement>
  <!-- Omit specific dependency management -->
</dependencyManagement>
<build>
  <pluginManagement>
    <!-- Omit specific build plug-in management -->
  </pluginManagement>
  <plugins>
    <!-- Omit specific build plug-ins -->
  </plugins>
</build>

As you can see from the pom, in addition to the introduction of (3) plug-ins, spring-boot-dependencies is more about version management.

Among them, the plug-ins introduced are:

• flatten-maven-plugin: streamlined plugin for pom
• xml-maven-plugin:1. Validate the XML file against the schema; 2. Transform the XML file using the XSLT style
• build-helper-maven-plugin: Specify multiple source directories

Almost all dependencies in the spring-boot project are managed in dependency management.

The various maven plug-ins that are commonly used are managed in pluginManagement, which is not detailed here.

It contains maven-clean-plugin, maven-compiler-plugin, maven-assembly-plugin, maven-war-plugin, maven-jar-plugin, spring-boot-maven-plugin, where the spring-boot-maven-plugin plugin is very important to the spring-boot project and the jar packaged by Maven is repackaged as an executable jar.

spring-boot-starter-parent (important)

Now that you have such rich dependencies and plug-in version management as spring-boot-dependencies, what about a spring-boot-starter-parent?

The parent project of spring-boot-starter-parent is spring-boot-dependencies, which contains no code and uses only POM to manage dependencies, pom.xml is as follows:

<parent>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-dependencies</artifactId>
  <version>${revision}</version>
  <relativePath>../../spring-boot-dependencies</relativePath>
</parent>
<artifactId>spring-boot-starter-parent</artifactId>
<packaging>pom</packaging>
<name>Spring Boot Starter Parent</name>
<description>Parent pom providing dependency and plugin management for applications
  built with Maven</description>
<properties>
  <main.basedir>${basedir}/../../..</main.basedir>
  <java.version>1.8</java.version>
  <!-- Resource Separator -->
  <resource.delimiter>@</resource.delimiter> <!-- delimiter that doesn't clash with Spring ${} placeholders -->
  <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
  <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
  <maven.compiler.source>${java.version}</maven.compiler.source>
  <maven.compiler.target>${java.version}</maven.compiler.target>
</properties>
<build>
  <resources>
    <resource>
      <directory>${basedir}/src/main/resources</directory>
      <filtering>true</filtering>
      <includes>
        <include>**/application*.yml</include>
        <include>**/application*.yaml</include>
        <include>**/application*.properties</include>
      </includes>
    </resource>
    <resource>
      <directory>${basedir}/src/main/resources</directory>
      <excludes>
        <exclude>**/application*.yml</exclude>
        <exclude>**/application*.yaml</exclude>
        <exclude>**/application*.properties</exclude>
      </excludes>
    </resource>
  </resources>
  <pluginManagement>
    <plugins>
      <!-- Omit other things you don't care about plugin -->
      <!-- spring-boot Provided maven Re-packaging plug-ins, important!!! -->
      <plugin>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-maven-plugin</artifactId>
            <executions>
              <execution>
                <id>repackage</id>
                <goals>
                  <goal>repackage</goal>
                </goals>
              </execution>
            </executions>
            <configuration>
              <mainClass>${start-class}</mainClass>
            </configuration>
          </plugin>
    </plugins>
  </pluginManagement>
  <plugins>
            <!-- Introduce public plug-ins: flatten-maven-plugin,xml-maven-plugin -->
  </plugins>

Characteristic

• Default compilation version: Java 1.8
• Source code: UTF-8
• Dependency Management inherited from spring-boot-dependencies
• The goal of spring-boot-maven-plugin is set to repackage
• maven resource filtering (application*.yml, application*.yaml, application*.properties, etc.), plug-in configuration
• Resource delimiter: "@", refers to the maven attribute in application*.yml with @, commonly used as follows: spring.application.name=@artifactId@

Note that, since the application.properties and application.yml files accept Spring style placeholders (${...}), the Maven filtering is changed to use @..@placeholders. (You can override that by setting a Maven property called resource.delimiter.)

Translate:

spring-boot-parent

<parent>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-dependencies</artifactId>
        <version>${revision}</version>
        <relativePath>../spring-boot-dependencies</relativePath>
</parent>
<artifactId>spring-boot-parent</artifactId>
<packaging>pom</packaging>
<dependencyManagement>
  <!-- Omit specific dependency management -->
</dependencyManagement>
<dependencies>
  <!-- Omit specific dependencies -->
</dependencies>
<build>
  <pluginManagement>
    <!-- Omit specific build plug-in management -->
  </pluginManagement>
  <plugins>
    <!-- Omit specific build plug-ins -->
  </plugins>
  <profiles>
    <!-- Omit Specific profile -->
  </profiles>
</build>

dependencyManagement

There are two parts:

• Internal unpublished spring-boot dependencies
• Additional Spring boot dependencies (not valid for users)

Therefore, the dependency management added here does not require the user to care about, which is good and reassuring.

dependencies

Public dependency, mainly some test dependencies, such as junit, hamcrest, mockito, spring-test, and assertion dependency: assertj.

plugins

Some plug-ins common to spring-boot have been added, such as maven-compiler-plugin, maven-jar-plugin, maven-war-plugin, maven-source-plugin, etc.

profiles

Users don't care at all.ellipsis

Choice

spring-boot-dependencies and spring-boot-starter-parent, spring-boot-parent all provide dependency management functionality, so which one do we use in the development process?

• spring-boot-parent: Uses the spring-boot open source project to manage other modules in the whole spring-boot-project project except spring-boot-starters, which are provided to each of our out-of-the-box triplet packages.
• Spring-boot-starter-parent: When we build a spring-boot project through Spring Initializr, the official default is to let us use the spring-boot-starter-parent, which is roughly what the official recommendation is to manage dependencies. After all, this method provides more dependencies, plug-in management, and is more suitable for use.
• spring-boot-dependencies: If, at the time of use, the project does not want to specify a parent project, or the parent project of the company must be used, dependency management can be introduced through dependency management.

With spring-boot-dependencies, special attention should be paid to adding spring-boot-maven-plugin when comparing spring-boot-starter-parent, as follows:

<build>
  <plugins>
    <plugin>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-maven-plugin</artifactId>
    </plugin>
  </plugins>
  <pluginManagement>
    <plugins>
      <plugin>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-maven-plugin</artifactId>
        <version>${springboot.version}</version>
      </plugin>
    </plugins>
  </pluginManagement>
</build>

As for the other additional specified jar s for spring-boot-starter-parent, add them as needed.

Actual use

When used in projects, all two-party and three-party jars should be managed in a unified manner. In addition to the dependencies provided by spring-boot, we have many jars to manage, such as mysql driver packages, mybatis packages, toolkits, or two-party packages within the company.Therefore, it is best to use a separate module to build your own dependencies or parent s.

To be continued

em...Is this the end of the writing?It doesn't seem there yet, but you need to carefully analyze how the next few specific dependencies are selected, such as: what logging framework does spring-boot choose, logback?log4j2?log4j?So what about spring-boot when the code is not implemented with the log specified by spring-boot?Looking forward to future updates?Or not, who knows?

Focus on source analysis in the field of java knowledge, understand framework/tool principles from source code, validate the application of CS expertise