maven 手册-CSDN博客

当配置多个远程仓库的时候maven会试图从多个仓库下载依赖,选取最先成功的。
profile:

激活profile的集中方法

maven -P 参数激活过个profile 格式

mvn deploy -Pdev -Pprod
复制代码

对应profile的默认激活只要其他的profile被通过其他方式激活了该模式激活的profile将失效。

    <profiles>
		<profile>
			<id>dev</id>
        <properties>
            <profiles.active>SNAPSHOT</profiles.active>
        </properties>
        <activation>
            <!-- 设置默认激活这个配置 -->
            <activeByDefault>ture</activeByDefault>
        </activation>
		</profile>

		<profile>
			<id>prod</id>
        <properties>
            <profiles.active1>Releases</profiles.active1>
        </properties>
        <activation>
            <!-- 设置默认激活这个配置 -->
        </activation>
		</profile>
			
	</profiles>

	<activeProfiles>
		<!-- <activeProfile>prod</activeProfile> -->
	</activeProfiles>
复制代码

更新策略
更新策略只针对SNAPSHOT版，强制更新命令参数 -U (比如: mvn clean install -U) 也只针对SNAPSHOT版。 Releases版想强制跟新需要把只能把本地仓库中对应的包删掉。
nexus中的库分为主要分为三种
Hosted : 本私服上的库。
Proxy : 代理的远程仓库，比如:central,aliyun.
group : 其他类型库的打包，对引用方来说就相当于一个普通的库。
deploy
同一个版本号能否多次deploy?

repositories->configuration->Deployment Policy->Allow Redeploy(可以重新发布)|Disable Redeploy(不可以重新发布)|Read only(只读)
复制代码

SNAPSHOT一般默认设置成Allow Redeploy Releases 一般默认设置为 Disable Redeploy

repository的属性
一个工程依赖于另一个项目的一个jar 的snapshot版本，但是maven编译的时候发现无法下载xxx-snapshot.jar 。到maven本地库目录查看，发现只有文件.lastUpdated 。而并没有jar文件。出了什么问题了？

<repository>
   <id>ummsSnaps</id>
      <url>https://team/nexus/content/repositories/snapshots</url>
      <snapshots>
         <enabled>false</enabled>
      </snapshots>
</repository>
复制代码

发现对snapshots的属性设置为false，这就告诉maven说不要从这个仓库下载快照版本。所以改为true。问题就解决了。

下面是一个说明：

<project>  
...  
  <repositories>  
    <repository>  
      <id>maven-net-cn</id>  
      <name>Maven China Mirror</name>  
      <url>http://maven.net.cn/content/groups/public/</url>  
      <releases>  
        <enabled>true</enabled>  
      </releases>  
      <snapshots>  
        <enabled>false</enabled>  
      </snapshots>  
    </repository>  
  </repositories>  
  <pluginRepositories>  
    <pluginRepository>  
      <id>maven-net-cn</id>  
      <name>Maven China Mirror</name>  
      <url>http://maven.net.cn/content/groups/public/</url>  
      <releases>  
        <enabled>true</enabled>  
      </releases>  
      <snapshots>  
        <enabled>false</enabled>  
      </snapshots>      
    </pluginRepository>  
  </pluginRepositories>  
...  
</project>  
复制代码

我们先看一下的配置，你可以在它下面添加多个，每个都有它唯一的ID，一个描述性的name，以及最重要的，远程仓库的url。此外，true告诉Maven可以从这个仓库下载releases版本的构件，而false告诉Maven不要从这个仓库下载snapshot版本的构件。禁止从公共仓库下载snapshot构件是推荐的做法，因为这些构件不稳定，且不受你控制，你应该避免使用。当然，如果你想使用局域网内组织内部的仓库，你可以激活snapshot的支持。

关于的更详细的配置及相关解释，请参考：http://www.sonatype.com/books/maven-book/reference_zh/apas02s08.html。

maven跳过单元测试-maven.test.skip和skipTests的区别
-DskipTests，不执行测试用例，但编译测试用例类生成相应的class文件至target/test-classes下。

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

maven的版本管理： Releases版一定要保证同一个版本号对应的jar是一模一样的要不容易出问题。比如:

项目组有5个人其中A发布了一个jar A-1.1-Release.jar 其他四个人把这个jar下载到了本地仓库,这时候A又将某个方法methdx()删掉了然后又重新deploy一遍但是版本号没变。这时候其他人有引用methdx()但是由于其他人本地已经缓存了老的A-1.1-Release.jar所以还能引用到，这时候项目组新来一个人B从git上checkout了一份引用到methdx()代码，但是这时候从仓库里down下来的代码A-1.1-Release.jar中没有methdx()方法，这时候就会出问题B检查了下版本号也是对的但是就是没有methdx()而其他人配置的是同样的版本号就没有问题于是B只好清楚缓存重新down试试，或者去nexus上手工down下了一份反编译看看有没有该方法发现没有只好从别人那里拷贝一份。但是如果B对maven、nexus的实现细节不了解的话问题解决起来会花费好多时间。
如果生产上的应用每次打包的时候都是先把本仓库中的所有依赖清空，重新下载依赖打包的话如果出现上面的场景也会出现问题。
项目组有5个人其中A发布了一个jar A-1.1-Release.jar 其他四个人把这个jar下载到了本地仓库,这时候A新加了一个方法methdx()了然后又重新deploy一遍但是版本号没变。这时候其他人有可能已经down下了老版的A-1.1-Release.jar所以不会重新去nexus down jar所以如果不升级版本号其他人只有把本地的A-1.1-Release.jar删掉重新down才能引用到。但是如果B对maven、nexus的实现细节不了解的话问题解决起来会花费好多时间。

maven的最近依赖原则:
我们有一个web应用resolve-web，该工程依赖于project-A和project-B，project-A依赖于project-common的1.0版本并调用其中的sayHello()方法。project-B依赖于project-C，而project-C又进一步依赖于project-common的2.0版本并调用其中的sayGoodBye()方法。project-common的1.0和2.0版本是不同的，1.0中之包含sayHello()方法，而2.0中包含了sayHello()和sayGoodBye()两个方法。整个项目的依赖关系如下图：

根据Maven的transitive依赖机制，resolve-web将同时依赖于project-common的1.0和2.0版本，这就造成了依赖冲突。而根据最近获胜策略，Maven将选择project-common的1.0版本作为最终的依赖。 这和Gradle不同，Gradle在默认情况下将选择最新的版本作为获胜版本。而对于Maven，由于proejct-common的1.0版本比2.0版本在依赖树中离resolve-web更近，故1.0版本获胜。在resolve-web中执行"mvn dependency:tree -Dverbose"可以看到resolve-web的依赖关系