MAVEN相关问题汇总

1，解决罐包冲突：

行家管理罐包依赖的时候，假如你的依赖包甲需要间接依赖乙的1.0版本，而你的工程里又需要用到乙的2.0版本，这个时候就可能会出现运行时罐子冲突的异常，会报java.lang.NoSuchMethodError或者java.lang.ClassNotFoundException，java.lang.NoClassDefFoundError

解决方法一：

（1）使用mvn依赖：树可以查看项目所有依赖树

或者使用mvn依赖：tree -Dverbose -Dincludes = org.springframework.boot（等号后接产生冲突的包名）

（2）使用<exclutions>标签可以排除某些依赖罐包

<exclusions>  
          <exclusion>  
            <groupId>org.springframework</groupId>  
            <artifactId>spring-beans</artifactId>  
          </exclusion>  
  </exclusions>  

解决方法二：

在父级POM中使用dependencyManagement管理公用的罐子版本，子类中引入自己需要的罐子版本，行家会优先使用子类的罐子。

2，dependencyManagement和依赖关系的区别

依赖关系即使在子项目中不写该依赖项，那么子项目仍然会从父项目中继承该依赖项（全部继承）

dependencyManagement 里只是声明依赖，并不实现引入，因此子项目需要显示的声明需要用的依赖如果不在子项目中声明依赖，是不会从父项目中继承下来的;只有在子项目中写了该依赖项，并且没有指定具体版本，才会从父项目中继承该项，并且版本和范围都读取自父POM;另外如果子项目中指定了版本号，那么会使用子项目中指定的罐子版本。在顶层POM中定义共同的依赖关系。同时可以避免在每个使用的子项目中都声明一个版本号，这样想升级或者切换到另一个版本时，只需要在父类容器里更新，不需要任何一个子项目的修改;如果某个子项目需要另外一个版本号时，只需要在依赖关系中声明一个版本号即可子类就会使用子类声明的版本号，不继承于父类版本号。

pom.xml  
//只是对版本进行管理，不会实际引入jar  
<dependencyManagement>  
      <dependencies>  
            <dependency>  
                <groupId>org.springframework</groupId>  
                <artifactId>spring-core</artifactId>  
                <version>3.2.7</version>  
            </dependency>  
    </dependencies>  
</dependencyManagement>  
  
//会实际下载jar包  
<dependencies>  
       <dependency>  
                <groupId>org.springframework</groupId>  
                <artifactId>spring-core</artifactId>  
       </dependency>  
</dependencies>

3，范围的分类的作用

编

默认就是编译，什么都不配置也就是意味着compile.compile表示被依赖项目需要参与当前项目的编译，当然后续的测试，运行周期也参与其中，是一个比较强的依赖。打包的时候通常需要包含进去。

测试

范围为测试表示依赖项目仅仅参与测试相关的工作，包括测试代码的编译，执行。比较典型的如junit的。

runntime

runntime表示被依赖项目无需参与项目的编译，不过后期的测试和运行周期需要其参与。与编译相比，展示跳过编译而已，说实话在终端的项目（非开源，企业内部系统）中，和编译区别不是很大。比较常见的如JSR×××的实​​现，对应的API jar是编译的，具体实现是运行时的，编译只需要知道接口就足够了.oracle jdbc驱动架包就是一个很好的例子，一般范围为runntime。另外runntime的依赖通常和可选的搭配使用，可选为真我可以用甲实现，也可以。用乙实现。

提供

提供意味着打包的时候可以不用包进去，别的设施（Web容器）会提供。事实上该依赖理论上可以参与编译，测试，运行等周期。相当于compile，但是在打包阶段做了exclude的动作。

系统

从参与度来说，也提供相同，不过被依赖项不会从行家仓库抓，而是从本地文件系统拿，需一定要配合Systempath下属性使用。

 

范围的依赖传递

。A-> B->Ç当前项目为甲，A依赖于B，B依赖于C.知道B在甲项目中的范围，那么怎么知道C在甲中的范围呢答案是： 
当Ç是测试或者提供时，C直接被丢弃，A不依赖℃; 
否则甲依赖C，C的范围继承于乙的范围。

4，行家常用命令

mvn -version查看maven的版本及配置信息

mvn archetype：create -DgroupId = DartifactId =构建java项目

mvn archetype：create -DgroupId = DartifactId = -DarchetypeArtifactId = maven-archetype-webapp创建web项目

mvn编译编译项目代码

mvn包打包项目

mvn package -Dmaven.test.skip = true打包项目时跳过单元测试

mvn test运行单元测试

mvn clean清除编译产生的目标文件夹内容，可以配合相应命令一起使用，如mvn clean package，mvn clean test

mvn install打包后将其安装在本地仓库

mvn deploy打包后将其安装到pom文件中配置的远程仓库

mvn eclipse：eclipse将maven生成eclipse项目结构

mvn eclipse：clean清除maven项目中eclipse的项目结构

mvn site生成站点目录

mvn dependency：list显示所有已经解析的所有依赖

mvn dependency：tree以树的结构展示项目中的依赖

mvn依赖：分析对项目中的依赖进行分析，依赖未使用，使用单未引入

mvn tomcat：运行启动tomcat

5，可选的标签

项目-A依赖项目-B，项目-B依赖项目-D时

如果我们不希望将项目D及其依赖项添加到项目A的类路径中，因为我们知道存储库中缺少某些Project-D的依赖项（例如，可能是Project-E），并且您不需要/想要该功能在Project-B中，无论如何都依赖于Project-D。在这种情况下，Project-B的开发人员可以提供对Project-D的依赖，即<optional> true </ optional>，如下所示：

<dependency>
  <groupId>sample.ProjectD</groupId>
  <artifactId>ProjectD</artifactId>
  <version>1.0-SNAPSHOT</version>
  <optional>true</optional>
</dependency>

所以当project-B的<optional> true </ optional>时，project-A中如果没有显式的引入项目-D，则项目-A不依赖project-D，即项目-A可以自己选择是否依赖项目-D

默认<optional>的值为false，即子项目必须依赖

6、编译时跳过测试的两种方式

-DskipTests，不执行测试用例，但编译测试用例类生成相应的class文件至target/test-classes下。

-Dmaven.test.skip=true，不执行测试用例，也不编译测试用例类。