远程仓库的认证
1、一般来说，远程仓库无须认证就可以访问
2、但有时候出于安全考虑，需要提供认证信息，为了防止非法的仓库访问，管理员为每个仓库提供了一组用户名及密码
3、这时为了让Maven访问仓库内容，就需要配置认证信息
如何配置认证信息？
1、配置认证信息和配置仓库信息不同，仓库信息可以直接配置在POM文件中，但是认证信息必须配置在settings.xml文件中
2、这是因为POM往往是被提交到代码仓库中供所有成员访问的，而settings.xml一般只放在本机。因此，在settings.xml中配置认证信息更为安全
在settings.xml中配置仓库认证信息
<settings>
...
<servers>
<server>
<id>my-proj</id>
<username>repo-user</username>
<password>repo-pwd</password>
</server>
</servers>
...
</settings>
对以上配置信息说明:
1、Maven使用settings.xml文件中并不显而易见的servers元素及其server子元素配置仓库认证信息
2、在该配置中仓库的认证用户名为repo-user，认证密码位repo-pwd
3、这里的关键是id元素，settings.xml中server元素的id必须与POM中需要认证的repository元素的id完全一致，换句话说，正是这个id将认证信息与仓库配置联系在了一起
私服的一大作用之部署第三方构件
1、第三方构件包括组织内部生成的构件，以及一些无法从外部仓库直接获取的构件
2、无论是日常开发中生成的构件，还是正式版本发布的构件，都需要部署到仓库中，供其他团队成员使用
在POM中配置构件部署地址
<project>
...
<distributionManagement>
<repository>
<id>proj-releases</id>
<name>Proj Release Repository</name>
<url>http://192.168.1.100/content/repositories/proj-releases</url>
</repository>
<snapshotRepository>
<id>proj-snapshots</id>
<name>Proj Snapshot Repository</name>
<url>http://192.168.1.100/content/repositories/proj-snapshots</url>
</snapshotRepository>
</distributionManagerment>
...
</project>
对上面的配置进行解释
1、distributionManagerment包含repository和snapshotRepository子元素，前者表示发布版本构件的仓库，后者表示快照版本的仓库
2、发布版本仓库和快照版本仓库都需要配置id、name和url
3、id为该远程仓库的唯一标识，name是为了方便人阅读，关键的url表示该仓库的地址
往远程仓库部署构件需要注意什么？
1、往远程仓库部署构件需要认证
2、在settings.xml中创建一个server元素，id与仓库的id匹配
使用mvn clean deploy
使用mvn clean deploy命令，将项目构建输出的构件部署到配置对应的远程仓库
如果项目当前的版本是快照版本，则部署到快照版本仓库地址，否则就部署到发布版本仓库地址
为什么要区分发布版和快照版呢？
考虑这样一种场景，小张在开发模块A的2.1版本，该版本还未正式发布，与模块A一同开发的还有模块B，它由小张的同事季MM开发，B的功能依赖于A。在开发过程中，小张需要经常将自己最新的构建输出，交给季MM，供她开发和测试调试，问题是，这个工作如何进行呢？
方案一：
让季MM自己签出模块A的源码进行构建。这种方法能够确保季MM得到模块A的最新构建，不过她不得不去构建模块A。多了一些版本控制和Maven操作还不算，当构件失败的时候，她会是一头雾水，最后不得不找小张解决。显然，这种方式是低效的
方案二：
重复部署模块A的2.1版本供季MM下载。虽然小张能够保证仓库中的构件是最新的，但对于Maven来说，同样的版本和同样的坐标就意味着同样的构件。因此，如果季MM在本机的本地仓库包含了模块A的2.1版本构件，Maven就不会再对照远程仓库进行更新。除非她每次执行Maven命令之前，清除本地仓库，但这种要求手工干预的做法显然也是不可取的
方案三：
不停更新版本2.1.1、2.1.2、2.1.3 ... ... 首先，小张和季MM两人都需要频繁地更改POM，如果有更多的模块依赖于模块A，就会涉及更多的POM更改；其次，大量的版本其实仅仅包含了微小的差异，有时候是对版本号的滥用
那么如何解决上述问题？
Maven的快照版本机制就是为了解决上述问题的，在该例中，小张只需要将模块A的版本设定为2.1-SNAPSHOT，然后发布到私服中，在发布的过程中，Maven会自动为构件打上时间戳。比如2.1-20091214.221414-13就表示2009年12月14日22点14分14秒的第13次快照。有了该时间戳，Maven就能随时找到仓库中该构件2.1-SNAPSHOT版本最新的文件，这时，季MM配置对于模块A的2.1-SNAPSHOT版本的依赖，当她构建模块B的时候，Maven会自动从仓库中检查模块A的2.1-SNAPSHOT的最新构件。当发现有更新时，便进行下载。默认情况下，Maven每天检查一次更新 (由仓库配置的updatePolicy控制)，用户也可以使用命令行-U参数强制让Maven检查更新，如mvn clean install -U
什么时候变成发布版本，为什么发布版本稳定，快照版本不稳定？
当项目经过完善的测试后需要发布的时候，就应该将快照版本更改为发布版本
例如，将2.1-SNAPSHOT更改为2.1，表示该版本已经稳定，且只对应了唯一的构件，相比之下2.1-SNAPSHOT往往对应了大量的带有不同时间戳的构件，这也决定了其不稳定性
对于快照版本的一些建议
快照版本只应该在组织内部的项目或模块间依赖使用，因为这时，组织对于这些快照版本的依赖具有完全的理解及控制权
项目不应该依赖于任何组织外部的快照版本依赖，由于快照版本的不稳定性，这样的依赖会造成潜在的危险。也就是说，即使项目构建今天是成功的，由于外部的快照版本依赖实际对应的构件随时可能变化，项目的构建就可能由于这些外部的不受控制的因素而失败