Problem reappearance:
The last time this friend asked me a question is that they are in the pom.xml dependency, see some of the situation is <scope>provided</scope>, 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 about the circumstances in which the scope would be set to provided, and the difference between the and scope set to compile.
Explain:
In fact, the problem is very simple.
In the case of Scope=compile (default scope), that is, the project is compiled, tested, and run with the artifact corresponding jar package in classpath.
In the case of scope=provided, the provided is considered to be the target container that has provide the artifact. In other words, it only affects the compilation, testing phase. In the compilation test phase, we need this artifact corresponding jar package in the classpath, and in the runtime, assume that the target container (such as our Liferay container) has provided this jar package, so we do not need this artifact corresponding jar package.
It sounds iffy, right, but it's not hard to understand. Give me an example of a scope=provided.
For example, suppose that our own project PROJECTABC has a class called C1, and this C1 will import this portal-impl artifact of the class B1, then in the compilation phase, we definitely need this B1, otherwise C1 pass compilation, Because our scope is set to provided, the compile phase works, so C1 compiles correctly. Test phase is similar, so ignore.
So in the end we're going to have to PROJECTABC deployed to the Liferay server, and this time, we found under $liferay-tomcat-home\webapps\root\web-inf\lib, There is already a portal-impl.jar in it, in other words, the container has provided the artifact corresponding jar, so we are in the runtime, this C1 class can directly use the B1 class in the Portal-impl.jar provided by the container without any problems.
The behavior of the actual plug-in:
Just now we are talking about the theoretical part, we look at the actual plug-in at runtime, how to distinguish between Scope=compile and scope=provided.
Doing an experiment can easily be found, when we use Maven install to generate the final component package Projectabc.war, in the web-inf/lib below, we will be labeled as the scope=compile of the component of the jar package, It does not contain the jar package of the widget that we are labeled as scope=provided. This also avoids the creation of package dependency conflicts when deployed to the target container.