Do you understand the use of optional and scope elements in Maven?

In the process of sorting out the project, I found that many developers were not familiar with the configuration of Maven dependency files, especially the use of Maven optional elements and scope elements. This results in publishing jars or war packages that are “fat,” slow to compile, and prone to jar collisions. This article starts with optional and scope usage scenarios to achieve a wave of project slimming.

Optional elements

For example, the hot deployment component Spring-boot-devtools that we often use in the project can be defined with the optional element. The corresponding POM file is configured as follows:

<! <dependency> <groupId>org.springframework.boot</groupId> <artifactId> Spring-boot-devtools </artifactId>  <optional>true</optional> </dependency>Copy the code

So what does it mean to set the optional element to true? Optional is an option when Maven relies on jars, indicating that the dependency is optional and not passed between projects. Optional is not set (default) or optional is false to pass dependencies.

The text description may be abstract, but A concrete example scenario is used for A more intuitive description. Assume that there are two projects A and B, where A is the parent project and B is the child project. Unit test dependencies are introduced in the parent project:

<dependency> <groupId> <artifactId>junit</artifactId> <version>4.12</version> </dependency>Copy the code

Here’s a look at the different values of the optional element.

Optional element default (false)

The optional element is true

Set the optional element to true when the parent project introduces junit dependencies. Subproject B then has more options.

If project B does not need the Junit JAR package, then no processing is required in its POM files. If project B also requires A jar dependency, there are two options: 1. Set the optional dependency in project A to false or remove it. Second, project B directly introduces the required dependency.

Parent inheritance

<dependencyManagement> <dependencies> <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>4.12</version> <optional>true</optional> </dependency> </dependencies> </dependencies>Copy the code

The scope elements

Now that we’re done with the optional element, let’s look at scope.

The scope element is primarily used to control the scope of dependencies, specifying the scope and transitivity of dependencies for the current package, which dependencies are available in which classpath. Common optional values are compile, provided, Runtime, test, system, and so on.

Compile

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
</dependency>
Copy the code

Test (n.)

Scope as test indicates that dependent projects only participate in the test process and will not be used during compilation, running, and packaging. The most common use is the unit test class:

<dependency>
    <groupId>junit</groupId>
    <artifactId>junit</artifactId>
    <version>4.12</version>
    <scope>test</scope>
</dependency>
Copy the code

Dependencies such as unit tests, if not set to scope test, will obviously be packaged and published, but will have no effect in the real environment.

Runntime (runtime)

< the dependency > < groupId > mysql < / groupId > < artifactId > mysql connector - Java < / artifactId > < version > 8.0.20 < / version > <scope>runtime</scope> </dependency>Copy the code

Provided (= provided)

Provided is suitable for compilation and testing environments and is similar to compile, but provide only works during compilation and testing. Provide is not packaged and is not transitive.

For example, spring-boot-Devtools and servlet-API mentioned above do not need to be hot deployed in production, while the latter is provided by the container and does not need to be introduced repeatedly.

<dependency>
    <groupId>javax.servlet</groupId>
    <artifactId>javax.servlet-api</artifactId>
    <scope>provided</scope>
</dependency>
Copy the code

system

<dependency> <groupId>sun.jdk</groupId> <artifactId>tools</artifactId> <version>1.5.0</version> <scope>system</scope> <systemPath>${java.home}/.. /lib/tools.jar</systemPath> </dependency>Copy the code

Transitivity of scope dependencies

The different parameter values of scope are explained above. For these parameter values, the dependency transitivity in multiple projects is as follows:

Where B depends on A and C depends on B. The key to transitivity is the scope value set when B depends on A. When B uses different values, the corresponding dependency relationship is as follows: When B depends on A through test or provided, C does not depend on A. When B depends on A via runtime or compile, C depends on A;

summary