Settings for scope in Maven's dependency management

In Maven's dependency management, the dependent scope settings are often used. Here we organize the use of various scopes and instructions, as well as practical experience in the use.

Usage scenarios and descriptions for scope

1.compile

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

2.provided

The container or JDK has provided scope, indicating that the dependency package has been provided by the target container (such as Tomcat) and the JDK and is only loaded and used in the compiled classpath, and is not included in the target package when packaged. The most common are the SERVLET-API and Jsp-api jar packages related to the Java EE specification, which are typically provided by the servlet container, without being packaged into a war package, and if not configured as provided, package them into the Project war package. In the version above Tomcat6, the program will not run correctly (the version does not match the situation).

3.runtime

Generally run and test environment use, compile time without adding classpath, packaging time will be packaged into the target package. It is generally more common to load by dynamic loading or interface reflection. This means that the program only uses the interface, there may be more than one, the runtime through the configuration file or jar package scanning dynamic loading situation. Typical include: JDBC Driver and so on.

4.test

The test scope, generally is the unit test scenario use, joins the CLASSPATH in the compilation environment, but does not join when packing, like JUnit and so on.

5.system

System-wide, similar to provided, only the dependency packages marked for that scope need to explicitly specify the file system-based jar package path. This scope is not recommended because you need to specify a local jar file path through Systempath. If it is based on an organization, a local image is generally established, and local or organization-based components are added to the local image management to avoid using the scope.

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