In Maven's dependency management, the scope setting of dependencies is often used. Here are the usage scenarios and descriptions of various scopes, as well as the practical experience in use.
Scope usage scenarios and descriptions
1.compile
The compilation scope, the default scope, is valid both in the classpath (compile environment) of the project environment and in packaging (if it is a WAR package, it will be included in the WAR package).
2.provided
Container or JDK has provided scope, indicating that the dependency package has been provided by the target container (such as tomcat) and JDK, and is only loaded and used in the compiled classpath, and will not be included in the target package when packaged. The most common are jar packages such as servlet-api and jsp-api related to the j2ee specification, which are generally provided by the servlet container and do not need to be packaged into the war package. If it is not configured as provided, package these packages into the project war package. Tomcat6 and above versions will conflict and cannot run the program normally (the version does not match).
3.runtime
Generally, it is used in the running and testing environment. It does not need to be added to the classpath when compiling, and it will be packaged into the target package when it is packaged. Generally, there are many cases of dynamic loading or interface reflection loading. That is to say, the program only uses the interface, there may be more than one, and the dynamic loading is scanned by the configuration file or the jar package at runtime. Typical include: JDBC driver and so on.
4.test
The test scope is generally used in unit test scenarios. The classpath is added to the compilation environment, but it will not be added during packaging, such as junit.
5.system
System scope, similar to provided, except that dependencies marked with this scope need to explicitly specify the path to the jar package based on the file system. 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 image is generally established, and the local or organizational basic components are added to the local image management to avoid the use of this scope.
practice:
- Provided is not transitive, that is, if you depend on a jar package whose scope of a jar is provided, then the jar will not be added to your project by relying on jar dependency transitivity in your project. .
- provided has inheritance. In the above case, if you need to uniformly configure the general provided dependencies of an organization, you can use parent and then inherit it in all projects.