Maven relies scope of meaning

https://www.jianshu.com/p/7145f01ac3ad

Maven relies scope of meaning

Maven sort out in detail the role of the Scope and content are copied someone else order a bit. Reference:
https://blog.csdn.net/claram/article/details/77646263
https://blog.csdn.net/kimylrong/article/details/50353161
https://blog.csdn.net/mn960mn/article/ details / 50894022

action scope element: the use of dependency control elements. Popular speaking, is to control the Jar package is loaded and used in what range.
scope explained as follows:

compile (default)

Meaning: compile is the default value if no value is specified scope, the default value of the element compile. It is dependent on the project need to be involved to compile the current project, testing, packaging, and other operational stage. When packing items often contain relied upon.

provided

Meaning: in theory, can be relied upon to participate in the project to compile, test, run phases, equivalent to compile, but then made a packed stage of action exclude.
Applicable scene: for example, if we develop a web application, at compile time, we need to rely on servlet-api.jar, but we do not need to run the jar package, because the jar package provided by the application server, then we need It is provided using a modified range.

runtime

Meaning: that was dependent on the project without the involvement of the compiled program, but will participate in the test and to run the project. Compared to compile, it is dependent on the project without the involvement of the compiled project.
Applicable scene: for example, in the translation of the jar package we do not need the JDBC API, but when we need to run the JDBC driver package.

test

Meaning: that was dependent on the project only involved in work-related tests, including compiling test code execution.
Applicable scene: for example, Junit test.

system

Meaning: system elements and provided similar elements, but does not look up from the dependencies maven repository, but from a local system, systemPath elements for the development of the local system path jar file. E.g:

<dependency>
    <groupId>org.open</groupId> <artifactId>open-core</artifactId> <version>1.5</version> <scope>system</scope> <systemPath>${basedir}/WebContent/WEB-INF/lib/open-core.jar</systemPath> </dependency> 

import

It is used only <dependencyManagement>, the dependency represented introduced from another pom configuration, such as (B project into the package configuration item A):

Surely we do SpringBoot application, that they will have the following code:

<parent>
    <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>1.3.3.RELEASE</version> </parent> 

Module inherits a parent, and then reintroduced into the respective dependent.
If you say, I do not want to inherit, or I want to inherit more, how do?

We know Maven Java inheritance and succession, is unable to achieve multiple inheritance, if 10, 20 or even more modules inherit from the same module, then in accordance with our previous practice, the parent module will contain a large number of dependencyManagement rely. If you want to classify these dependencies clearer management, it is impossible, import scope dependence can solve this problem. You can put into separate dependencyManagement dependence is used to manage the pom, then import scope dependent, can be incorporated in a module requires dependencyManagement dependent of. For example, you could write such a pom for the dependency management:

<project>
    <modelVersion>4.0.0</modelVersion> <groupId>com.test.sample</groupId> <artifactId>base-parent1</artifactId> <packaging>pom</packaging> <version>1.0.0-SNAPSHOT</version> <dependencyManagement> <dependencies> <dependency> <groupId>junit</groupId> <artifactid>junit</artifactId> <version>4.8.2</version> </dependency> <dependency> <groupId>log4j</groupId> <artifactid>log4j</artifactId> <version>1.2.16</version> </dependency> </dependencies> </dependencyManagement> </project> 

Then I'll be able to introduce this dependency management configuration by way of non-inherited

<dependencyManagement>
    <dependencies>
        <dependency> <groupId>com.test.sample</groupId> <artifactid>base-parent1</artifactId> <version>1.0.0-SNAPSHOT</version> <type>pom</type> <scope>import</scope> </dependency> </dependencies> </dependencyManagement> <dependency> <groupId>junit</groupId> <artifactid>junit</artifactId> </dependency> <dependency> <groupId>log4j</groupId> <artifactid>log4j</artifactId> </dependency> 

Note: import scope can only be used inside dependencyManagement

In this way, pom parent module will be very clean, single responsibility principle by special packaging for the pom to manage dependencies, but also fit the object-oriented design. In addition, we can create more of these dependency management pom, in a more refined way to manage dependencies. This approach combined with the use of object-oriented design rather than inherited a bit like the taste.

So, how to use this method to solve the succession problem SpringBoot it?

Configuration is as follows:

<dependencyManagement>
    <dependencies>
        <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-dependencies</artifactId> <version>1.3.3.RELEASE</version> <type>pom</type> <scope>import</scope> </dependency> </dependencies> </dependencyManagement> <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> </dependencies> 

So configured that their projects do not need to inherit SpringBoot inside the module, the module can be inherited and own the project.

dependent transfer scope

A-> B-> C. The current project is A, A is dependent on B, B depends on C. A knows B scope in the project, then how do you know in A C scope of it? The answer is:
when the test or C is provided, C is directly discarded, A does not depend on C;
or A-dependent C, C inherits from the scope of the B scope.

Here is a nexus drawn map.