The settings for the scope in Maven's dependency management

In Maven's dependency management, dependent scope settings are often used. Here is a list of various scope usage scenarios and instructions, as well as practical experience in use.

Scope of use scenarios and descriptions

1.compile

The compilation scope, default scope, is valid in the CLASSPATH (compilation environment) of the engineering environment and packaged (if the war package is included in the war package).

2.provided

A container or JDK provides a scope that indicates that the dependency package is already provided by the target container (such as Tomcat) and JDK and is loaded and used only in the compiled Classpath and is not included in the target package when packaged. The most common is the Java EE Specification-related jar packages such as Servlet-api and JSP-API, which are typically provided by the servlet container, and packaged into the project war package without being packaged into the war package, if not configured as provided, There will be conflicting versions of the program that are not running correctly in Tomcat6 version (version mismatch).

3.runtime

Generally run and test environment use, compile time without adding classpath, packaging time will be packaged into the target package. More often than not, it is loaded by dynamic loading or interface reflection. That is, the program only uses the interface, the specific time may have multiple, runtime through the configuration file or jar package scan dynamic loading. Typical includes: JDBC driver, and so on.

4.test

Test scope, typically used for unit test scenarios, add classpath to the build environment, but not add to the package, such as JUnit.

5.system

System-wide, similar to provided, only a dependent package marked for that scope needs to explicitly specify the filesystem-based jar package path. This scope is not recommended because the local jar file path needs to be specified through Systempath. If it is based on an organization, a local mirror is typically created, and local or organizational infrastructure components are added to local mirroring management to circumvent the use of the scope.

Practice: provided is not transitive, that is, if you rely on a jar package whose scope is provided, the jar will not be added to your project by relying on jar-dependent delivery in your project. provided is inherited, and in the case of the above, if you need to uniformly configure a common provided dependency for an organization, you can use parent and then inherit from all projects.