XX项目知识点汇总(3)

XX项目知识点汇总(3)
1.maven dependencies与dependencyManagement的区别
首先新建三个项目，Parent作为父项目、projectA、projectB作为子项目。
在父项目Parent中依赖项如下：
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.8.1</version>
<scope>test</scope>
</dependency>
</dependencies>
在子项目projectA、projectB中没有写任何依赖，在projectA 下运行命令 mvn help:effective-pom,会发现A下面有 junit 4.8.1的依赖。
如果我把 父项目Parent 中的依赖修改如下：
<dependencyManagement>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.8.1</version>
<scope>test</scope>
</dependency>
</dependencies>
</dependencyManagement>
子项目ProjectA、projectB下面还是没有任何依赖项，在projectA 下运行命令 mvn help:effective-pom,会发现A下面 没有 junit 4.8.1的依赖。
我在projectA 下添加junit的依赖：
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
</dependency>
</dependencies>
再在projectA 下运行命令 mvn help:effective-pom,会发现A下面有了 junit 4.8.1的依赖，并且scope为 test。
那么经过验证，scope写在子项目中的<dependencies> 下的<dependency>中，或是写在父项目中的<dependencyManagement>中，都是可以的。
但有一点需要注意，dependencies 和 dependencyManagement 的区别在于：
前者，即使在子项目中不写该依赖项，那么子项目仍然会从父项目中继承该依赖项。
后者，如果在子项目中不写该依赖项，那么子项目中是不会从父项目继承该依赖项的；只有在子项目中写了该依赖项，才会从父项目中继承该项，并且version 和 scope 都读取自 父pom。
这样做的目的是：
　　统一管理项目的版本号，确保应用的各个项目的依赖和版本一致，才能保证测试的和发布的是相同的成果，因此，在顶层pom中定义共同的依赖关系。同时可以避免在每个使用的子项目中都声明一个版本号，这样想升级或者切换到另一个版本时，只需要在父类容器里更新，不需要任何一个子项目的修改；如果某个子项目需要另外一个版本号时，只需要在dependencies中声明一个版本号即可。子类就会使用子类声明的版本号，不继承于父类版本号。
区别
　　　dependencies即使在子项目中不写该依赖项，那么子项目仍然会从父项目中继承该依赖项（全部继承）
      dependencyManagement里只是声明依赖，并不实现引入，因此子项目需要显示的声明需要用的依赖。如果不在子项目中声明依赖，是不会从父项目中继承下来的；只有在子项目中写了该依赖项，并且没有指定具体版本，才会从父项目中继承该项，并且version和scope都读取自父pom;另外如果子项目中指定了版本号，那么会使用子项目中指定的jar版本。
2.pluginManagement：
作用类似于dependencyManagement， 定义子项目中的插件。 这样在子项目中使用插件时，可以不用指定其版本，由父项目统一进行管理。
3.中央仓库的使用
<repositories>
<repository>
    <snapshots>
        <enabled>false</enabled>
    </snapshots>
    <id>central</id>
    <name>bintray</name>
    <url>http://jcenter.bintray.com</url>
</repository>
</repositories>
1)笨方法：
把缺失的jar包的groupId artifactId 和version都找到，然后放到网上搜，把下载的jar包放在指定的localrepository之下。
2)正确的方式：
为pom.xml添加正确的repository。
4.Maven最佳实践-distributionManagement
    本地仓库 的更新
        mvn  clean package install
    远程 仓库 的更新
        mvn clean package deploy
  在使用maven过程中，我们在开发阶段经常性的会有很多公共库处于不稳定状态，随时需要修改并发布，可能一天就要发布一次，遇到bug时，甚至一天要发布N次。我们知道，maven的依赖管理是基于版本管理的，对于发布状态的artifact，如果版本号相同，即使我们内部的镜像服务器上的组件比本地新，maven也不会主动下载的。如果我们在开发阶段都是基于正式发布版本来做依赖管理，那么遇到这个问题，就需要升级组件的版本号，可这样就明显不符合要求和实际情况了。但是，如果是基于快照版本，那么问题就自热而然的解决了，而maven已经为我们准备好了这一切。
  maven中的仓库分为两种，snapshot快照仓库和release发布仓库。snapshot快照仓库用于保存开发过程中的不稳定版本，release正式仓库则是用来保存稳定的发行版本。定义一个组件/模块为快照版本，只需要在pom文件中在该模块的版本号后加上-SNAPSHOT即可(注意这里必须是大写)，如下：
    <groupId>cc.mzone</groupId>  
    <artifactId>m1</artifactId>  
    <version>0.1-SNAPSHOT</version>  
    <packaging>jar</packaging>  
      maven会根据模块的版本号(pom文件中的version)中是否带有-SNAPSHOT来判断是快照版本还是正式版本。如果是快照版本，那么在mvn deploy时会自动发布到快照版本库中，而使用快照版本的模块，在不更改版本号的情况下，直接编译打包时，maven会自动从镜像服务器上下载最新的快照版本。如果是正式发布版本，那么在mvn deploy时会自动发布到正式版本库中，而使用正式版本的模块，在不更改版本号的情况下，编译打包时如果本地已经存在该版本的模块则不会主动去镜像服务器上下载。
      所以，我们在开发阶段，可以将公用库的版本设置为快照版本，而被依赖组件则引用快照版本进行开发，在公用库的快照版本更新后，我们也不需要修改pom文件提示版本号来下载新的版本，直接mvn执行相关编译、打包命令即可重新下载最新的快照库了，从而也方便了我们进行开发。
接下来要介绍的是如何在项目中应用snapshot和release库，应用snapshot和release库达到不同环境下发布不同的版本的目的，首先看一个pom文件的定义：
    <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"  
             xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">  
        <modelVersion>4.0.0</modelVersion>  
        <groupId>net.aty.mybatis</groupId>  
        <artifactId>mybatis-demo</artifactId>  
        <packaging>jar</packaging>  
        <version>${project.release.version}</version>  
        <name>mybatis-demo</name>  
        <url>http://maven.apache.org</url>          
        <properties>  
            <project.release.version>0.1-SNAPSHOT</project.release.version>  
        </properties>           
        <profiles>  
            <profile>  
                <id>release</id>  
            <properties>  
                <project.release.version>0.1</project.release.version>  
            </properties>  
            </profile>  
        </profiles>   
        <!--定义snapshots库和releases库的nexus地址-->  
        <distributionManagement>  
            <repository>  
                <id>nexus-releases</id>  
                <url>  
                    http://172.17.103.59:8081/nexus/content/repositories/releases/  
                </url>  
            </repository>  
            <snapshotRepository>  
                <id>nexus-snapshots</id>  
                <url>  
                    http://172.17.103.59:8081/nexus/content/repositories/snapshots/  
                </url>  
            </snapshotRepository>  
        </distributionManagement>  
    </project>  
  首先我们看到pom文件中version的定义是采用占位符的形式，这样的好处是可以根据不同的profile来替换版本信息，比如maven默认是使用0.1-SNAPSHOT作为该模块的版本。
1、如果在发布时使用mvn deploy -P release 的命令，那么会自动使用0.1作为发布版本，那么根据maven处理snapshot和release的规则，由于版本号后不带-SNAPSHOT故当成是正式发布版本，会被发布到release仓库；
2、如果发布时使用mvn deploy命令，那么就会使用默认的版本号0.1-SNAPSHOT，此时maven会认为是快照版本，会自动发布到快照版本库。
   在distributionManagement段中配置的是snapshot快照库和release发布库的地址，我这里是采用nexus作为镜像服务器。对于版本库主要是id和url的配置，配置完成后就可以通过mvn deploy进行发布了，当然了，如果你的镜像服务器需要用户名和密码，那么还需要在maven的settings.xml文件中做如下配置：
    <server>  
      <id>nexus-releases</id>  
      <username>admin</username>  
      <password>admin123</password>  
    </server>  
    <server>  
      <id>nexus-snapshots</id>  
      <username>admin</username>  
      <password>admin123</password>  
    </server>  
  注意这里配置的server的id必须和pom文件中的distributionManagement对应仓库的id保持一致，maven在处理发布时会根据id查找用户名称和密码进行登录和文件的上传发布。
  我们这里通过profile的定义就可以在发布灵活切换snapshot快照版本和release正式版本了，在被依赖的组件中也可以使用profile来定义在开发阶段使用快照库，在发布阶段使用正式库的功能，只需要在不同的profile中覆盖默认的properties属性值即可。