Posted Jun 26, 2020 • 2 min read
The default is compile, and configuring nothing means compile. Compile indicates that the dependent project needs to participate in the compilation of the current project. Of course, subsequent tests and running cycles are also involved, which is a relatively strong dependency. It usually needs to be included when packaging.
It means that the dependent project is only involved in test-related work, including the compilation and execution of test code. Typical ones are junit.
It means that the dependent project does not need to participate in the compilation of the project, but it needs its participation in the later testing and running cycle. Compared with compile, skip compiling,
To be honest, in terminal projects(non-open source, enterprise internal systems), it is not very different from compile. The more common implementations such as JSR×××, the corresponding API jar is compile,
The specific implementation is runtime, and compile only needs to know the interface. Oracle jdbc driver rack package is a good example, the general scope is runntime.
In addition, the dependency of runntime is usually used in conjunction with optional, optional is true. I can do it with A or B.
It means you don't need to pack in when packing, other facilities(Web Container ) will provide. In fact, the dependency can theoretically participate in the compilation, testing, and operation cycles. Equivalent to compile, but did exclude action in the packaging stage.
For example, a web application may require the available Servlet API in the compile classpath to compile a servlet, but it will not be included in the packaged WAR;
The Servlet API JAR is provided by the application server or servlet container. Dependencies of the provided scope are available in the compiled classpath(not the runtime). They are not transitive, nor will they be packaged.
The system scope dependency is similar to provided, but you must explicitly provide a path to the JAR file in the local system. This is done to allow compilation based on local objects,
These objects are part of the system library. Such a component should always be available, and Maven will not look for it in the warehouse. If you set a dependent scope to system scope, you must also provide a systemPath element. Note that this range is not recommended(you should always try to reference dependencies from public or custom Maven repositories).
A >B >C
The current project is A, A depends on B, and B depends on C. When the scope of C is test or provided, C is directly discarded, and A does not depend on C;
Otherwise, A depends on C, and C's scope inherits from B's scope.