of pom If the parent pom uses the <dependencies>....</dependencies> method, the child pom will automatically use the jar package in the pom, if the parent pom uses <dependencyManagement><dependencies>.. ..</dependencies></dependencyManagement> method, the child pom will not automatically use the jar package in the parent pom, then if the child pom wants to use it, the groupId and artifactId must be given, no need to give version
2. Dependency To manage
the life cycle of maven, http://www.cnblogs.com/tenghoo/p/maven_life_cycle.html
Maven has three independent life cycles, namely clean, default and site. Each life cycle contains some phases (phases), the phases are sequential, and the later phases depend on the previous ones. Each life cycle is independent of each other (for example, if mvn package is executed, the clean operation will not be performed ), and the stages of a life cycle depend on each other (for example, when mvn package is executed, the validate, compile, and test stages before the package will be automatically executed ).
2.1 Transitive Dependency (transitive dependency)
Your project depends on A, and A depends on B. Is your project going to declare that you depend on B? Maven's answer is that it automatically manages the transitivity of this dependency for you, you don't need to declare that you depend on B, it's up to Maven to do it (that's transitive dependencies).
But if A -> B -> C -> D 2.0, and A -> E -> D 1.0 exists at the same time, should you use D1.0 or D2.0? In Maven's words, this matter is called "Dependency Mediation" . When such a conflict occurs, the "Nearest Definition" solution is adopted, that is, the shortest path is adopted . In the above example, the result of the arbitration is D1. 0 because its path is shorter. What if the two paths are the same length? Then you can only choose whoever appears first. In the above example, if you explicitly state that A depends on D2.0, then Maven will choose D2.0 for you instead of D1.0. This sometimes leads to some version inconsistency issues and doubts.
Best practice to avoid version problems caused by transitive dependencies: Many open source frameworks and tools are now packaged and released in modules, such as spring and hibernate, and there may be related dependencies between these modules. The problem of version inconsistency. For example, spring-jms in the above example uses 3.0.2, while spring-core uses 3.0.3. This requires us to have multiple modules of a framework that a project directly depends on. To make a declaration, instead of relying on its internal dependencies to import indirectly. To sum up: Generally speaking, if the project directly depends on multiple modules of a framework, it is best to declare all these dependencies.
http://www.cnblogs.com/alfredxiao/archive/2010/09/15/maven_dependency_mgmt.html
http://blog.csdn.net/bluishglc/article/details/6584678
2.2 Dependency Scope
For example, you need to test when you develop, you need to depend on the junit jar, but you don't need it when deploying the application, because the unit test will not run in the production environment, which means that the final packaged jar or war does not contain jar of junit. Another example is when you develop a web program, your servlet/jsp needs to depend on the standard api of servlet-jsp (J2EE jar) for compilation, but it is not needed during deployment, because your application server must have these things.
Therefore, Maven considers 6 possible scopes to choose from:
- compile: the default scope . Compilation, testing, packaging are all required. Compile participates in dependency transfer, that is, your project A depends on B (the dependency scope is compile), and project C depends on your project A, then C also depends on B.
- provided: Indicates that the JDK or container will provide these (jar) at runtime, such as the servlet api mentioned above. The provided things will be used when compiling and testing, and do not participate in transitive dependencies.
- runtime: Indicates that it is not required for compilation, but is required for testing and runtime, and will be included in the final package.
- test: only used in the test phase (test compilation and test execution ), typically the junit jar.
- system: Similar to provided, but requires that the jar is already in your system and will not be found in the repository, such as rt.jar, tools.jar.
- import: Simply put, the pom of your project can inherit the pom of another project, thus inheriting the dependencies of the parent project, but because of the limitation of single inheritance later, import was created so that you can "import" or say "Inherit" the dependencies of any one or more projects.
If your project depends on A (scope1) and A depends on B (scope2), which scope should your project depend on B? There is a table on the official document that lists a matrix relationship between scope1 and scope2.
2.3 Dependency conflict resolution
As mentioned above, in order to prevent version conflicts caused by transitive dependencies, you can declare all the projects that the project depends on in the project, but if you don't do this and want to avoid the version problem of a jar package, you can exclude the specified jar package dependency as follows Pass:
<exclusions>
<exclusion>
<artifactId>asm</artifactId>
<groupId>asm</groupId>
</exclusion>
</exclusions>
2.4 IDE dependency management
In idea, you can right-click on a pom file
to see The dependencies of the pom file, you can zoom in or choose a different layout to show this relationship. Right-click a jar dependency to perform operations such as exclude. Changes to the pom file idea will not automatically update this dependency graph, you need to right-click on the pom file maven->reimport to reload. Of course, you can also view the dependency tree through the maven command: mvn dependency:tree
3. For multi-module projects and multi-war package projects, you can choose to only hit a war to get
the maven reactor function:
mvn package -pl module-name/ -am
Note -am is to compile the modules that module-name depends on at the same time, and -amd is the reverse dependency.
4. To skip a module when deploying, add the following
<build>
<plugins>
<plugin>
<artifactId>maven-deploy-plugin</artifactId>
<version>2.8.2</version> in the pom of the module
<configuration>
<skip>true</skip>
</configuration>
</plugin>
</plugins>
</build>