背景

一个不能算大的标准化框架项目，部署到客户端进行开发。不能联网，只能用他们的远程仓库，大多数jar包都低于项目一个版本。

方案一：修改jar版本匹配仓库

先是说上传项目依赖jar包不容易巴拉巴拉，又说低一个版本基本没有什么改变。我一想，好像是这么一回事。嗯，好，那开始吧！

  1. 修改主包版本号，将影响所有子包的版本；
    比方说一个主包的版本是2.1，那么一般情况下，子包依赖的版本都是2.1，但也有例外。这样就会有牵一发而动全身的感觉。
  2. 主包不一定能决定子包的版本号：
    主包明明在父项目中声明了版本号，但是子项目中仍要求我声明子包版本号。
  3. jar包关系维护混乱：
    经常会因为修改了一个jar版本，导致要修改另一个jar版本。而且并非所有最新版本的jar依赖的其他jar包也是最新的。比方A1需要B1版本，但实际仓库只有B2以上的版本。

实际操作中，我既可能需要降低某个jar包的版本，又可能需要升高某个jar的版本，然后根据项目报错一个个解决依赖。客户方以为很容易，但实际中涉及要考虑的依赖关系太复杂，就好像解决一团毛线。而且，我并不是标准项目开发人，并不知道哪些类一定要什么版本才有。

方案二：使用本地仓库

本来按理说用远程仓库是极好的，便于jar管理嘛。但上面的方式配置了好久，一个依赖解决完，引发另一个依赖。就好比走迷宫，一条道走下去死胡同，还得回头 重新选方向。哎，命苦。实在进度不佳，还无法预估完成时间。为了不影响其他人敲代码，只能选本地仓库的模式。

  1. 明明使用了本地仓库，但仍无法建立依赖；
    本地仓库配置没有问题，jar包也存在，但是依赖关系无法生成。查看进度时发现，maven它找的是远程仓库的地址（ps：地址已经配置为不可连接的地址，也尝试过删除）。
    无论如何配置都不能maven去读我的本地。

方案三：上传所有依赖

经过又一段时间的消耗，客户终于同意使用我们所有的jar包版本（ps：后来发现不少新的jar包才有的类被我们使用到了，有时候太先进也不好。。。）

  1. jar包冲突，无法下载我指定的版本；
    原有是provided 配置的jar包中强制规定了另一个版本，我一直以为不会影响jar包的版本。
  2. maven的先本地的原则并非一定生效；
    我本地已有jar包，在update时没有勾选odffline时，出错。
    当我选择offline模式时，正确。
  3. 几乎同样的配置，主包可以下载下来，但子包下载失败：
    只那位同事存在这个问题，主包pom文件都指明了需要依赖的包。远程仓库连接正常，毕竟主包可以下载。maven配置一致，eclipse一致。拷贝jar的方法无效，因为前面说明，没法指定maven使用本地的jar包。

总结

maven既是地狱又是天堂，有网的情况下是天堂，没网的情况下是地狱。也许很多人都觉得maven不需要什么深刻的学习，毕竟只是工具。而且确实对于我们来说，要学的东西实在太多，无法兼顾。但是道理，总是那个道理的，或者说套路。为什么说要了解原理呢？因为了解了，你才知道它真正是怎么做，而不是你觉得它是怎样做的。
就像这个maven ，我不明白它为什么放着我给它的本地仓库不用，非要去找远程。

明明指明了要下载主包下面的子包，却只是下了主包。