maven dependent scope = compile and provided the difference in dependency

To reproduce the problem

Last here friend asked me a question, that is, they are in the pom.xml dependency, we see there are some cases provided, such as the following:

<dependency> 
   <groupId>com.liferay.portal</groupId> <artifactId>portal-impl</artifactId> <version>6.1.0</version> <scope>provided</scope> </dependency>

They asked me to scope the circumstances in which you want to set as provided, and the scope and set to compile the difference.

Explanation

In fact, this question is very simple.
In the case of (scope = compile the default scope ), that is to say in this project to compile, test, run stage requires this artifact (module) corresponding jar package in the classpath.
As for the case of scope = provided, you may think that this is the target container has been provided provide this artifact. In other words, it only affects compile, test phase. In compiling the testing phase, we need this artifact corresponding jar package in the classpath, and in the operational phase, assume that the target container (such as we have here liferay container) has provided the jar package, there is no need of our artifact corresponding jar package a.

Examples (scope = provided)

For example, assume that our own projects ProjectABC there is a class called C1, C1 and this will import this portal-impl of artifact in class B1, then at compile time, we certainly need this B1, C1 or not compile, because our scope to provided, so the compilation stage work, so C1 right by the compiler. Similar testing phase, it is ignored.
So finally we want it ProjectABC deployed to the Liferay server, and this time, we went to $liferay-tomcat-home\webapps\ROOT\WEB-INF\libthe next discovery, which already has a portal-impl.jar, in other words, the container has provided this artifact corresponding jar, so we in the operational phase, the class C1 may directly portal-impl.jar class B1 provided in the container, without any problems.

The actual plug-in behavior

We have just the story of the theoretical part, and now we look at the actual plug-in running time, is how to distinguish between scope = compile and scope = provided the conditions.
An experiment can be easily found that when we generate a final package member ProjectABC.war with maven install, the WEB-INF under the in / lib, we will be denoted as containing scope = jar compile the package member, we will not be labeled as containing scope = provided jar package member. This also avoids the generation of such member when the package is dependent conflict deployed to the target vessel.

Dependent range

Three classpath maven
compile, test, run
1.compile: default range, compile the test run are valid
2.provided: Effective when compiling and testing
3.runtime: effective in testing and runtime
4.test: only when the test effective
5.system: valid when compiled and tested, associated with the present system, poor portability

pom.xml common elements introduced

Information project includes pom some of the constraints of
modelVersion specify the current version of the pom of
groupId (main item marked, defining the current maven belongs to which project writeback company web site + project name),
artifactId (actual project module identification, project name + module name),
Version (the current project version, first identifies the major version number 0, 0 marked the second branch version number, and the third 0 indicates minor version number, 0.0.1, snapshot snapshot, alpha-house testing, beta beta, release and stability, GA officially released)
name item description name
url address project
description project description
developers developers list
licenses permit
organization: organizational
dependencies: dependency list
dependency: dependence coordinate the project which placed
scope: the scope of the package depend on the Test
optional: setting depends on whether the optional
exclusions : exclude transitive dependencies list
dependencyManagement dependent management
build: build support for acts of
plugins: plugins list
parent: child inherits the parent module module
modules: aggregate multiple maven projects

reference:

http://supercharles888.blog.51cto.com/609344/981316/

from:https://blog.csdn.net/mccand1234/article/details/60962283