internal repository是指在局域网内部搭建的repository，它跟central repository, jboss repository等的区别仅仅在于其URL是一个内部网址
mirror则相当于一个代理，它会拦截去指定的远程repository下载构件的请求，然后从自己这里找出构件回送给客户端。配置mirror的目的一般是出于网速考虑。
可以看出，internal repository和mirror是两码事。前者本身是一个repository，可以和其它repository一起提供服务，比如它可以用来提供公司内部的maven构件；而后者本身并不是repository，它只是远程repository的网络加速器。
不过，很多internal repository搭建工具往往也提供mirror服务，比如Nexus就可以让同一个URL,既用作internal repository，又使它成为所有repository的mirror。
如果仓库X可以提供仓库Y存储的所有内容，那么就可以认为X是Y的一个镜像。换句话说，任何一个可以从仓库Y获得的构件，都胡够从它的镜像中获取。举个例子，http://maven.net.cn/content/groups/public/ 是中央仓库http://repo1.maven.org/maven2/ 在中国的镜像，由于地理位置的因素，该镜像往往能够提供比中央仓库更快的务。因此，可以配置Maven使用该镜像来替代中央仓库。编辑settings.xml，代码如下：
《settings》
...
《mirrors》
《mirror》
《id》maven.net.cn《/id》
《name》one of the central mirrors in china《/name》
《url》http://maven.net.cn/content/groups/public/《/url》
《mirrorOf》central《/mirrorOf》
《/mirror》
《/mirrors》
...
《/settings》
该例中，《mirrorOf》的值为central，表示该配置为中央仓库的镜像，任何对于中央仓库的请求都会转至该镜像，用户也可以使用同样的方法配置其他仓库的镜像。另外三个元素id,name,url与一般仓库配置无异，表示该镜像仓库的唯一标识符、名称以及地址。类似地，如果该镜像需认证，也可以基于该id配置仓库认证。
关于镜像的一个更为常见的用法是结合私服。由于私服可以代理任何外部的公共仓库(包括中央仓库)，因此，对于组织内部的Maven用户来说，使用一个私服地址就等于使用了所有需要的外部仓库，这可以将配置集中到私服，从而简化Maven本身的配置。在这种情况下，任何需要的构件都可以从私服获得，私服就是所有仓库的镜像。这时，可以配置这样的一个镜像，如例：
《settings》
...
《mirrors》
《mirror》
《id》internal-repository《/id》
《name》Internal Repository Manager《/name》
《url》http://192.168.1.100/maven2《/url》
《mirrorOf》*《/mirrorOf》
《/mirror》
《/mirrors》
...
《/settings》
该例中《mirrorOf》的值为星号，表示该配置是所有Maven仓库的镜像，任何对于远程仓库的请求都会被转至http://192.168.1.100/maven2/。如果该镜像仓库需要认证，则配置一个Id为internal-repository的《server》即可。为了满足一些复杂的需求，Maven还支持更高级的镜像配置：
1.《mirrorOf》*《/mirrorOf》
匹配所有远程仓库。
2.《mirrorOf》external:*《/mirrorOf》
匹配所有远程仓库，使用localhost的除外，使用file://协议的除外。也就是说，匹配所有不在本机上的远程仓库。
3.《mirrorOf》repo1,repo2《/mirrorOf》
匹配仓库repo1和repo2，使用逗号分隔多个远程仓库。
4.《mirrorOf》*,!repo1《/miiroOf》
匹配所有远程仓库，repo1除外，使用感叹号将仓库从匹配中排除。
需要注意的是，由于镜像仓库完全屏蔽了被镜像仓库，当镜像仓库不稳定或者停止服务的时候，Maven仍将无法访问被镜像仓库，因而将无法下载构件。
京公网安备 11010802041100号