在实际工作当中，很多时候会遇到一些有意思的事情，这些事情可能你原本压根没在意过，或者一丁点都不知道，但是在某一些卡住你过不去不得不解决而又解决了的经历之后，你的那种喜悦感，以及收获感，是非常丰富而满足的，今天，我就来记录一下工作中与 maven 这个并不太多打交道的工具之间的小故事两则。

故事一：编译的配置指向。

这个故事事实上在写 Jenkins 配置的那篇文章里边已经表达过了，这里简单概述一下，然后留下那里的详细链接。

故事非常简单，就是我们运维这边以前在打包的时候从来都是用下边的命令：

mvn clean install -Dmaven.test.skip=true

这没有什么毛病，但是因为在编译的时候只能读取默认的在主机的/root目录下生成的antx.properties文件，这会导致一些配置方面的问题，带来一点点麻烦，直到有一天一个同事划了一个圈，就彻底改变了命运：

mvn clean install -Dmaven.test.skip=true -Dautoconfig.userProperties=/root/pre_config/antx.properties_pre

从此以后再也不担心关于配置的复杂问题了，直接进行读取的指向，就一劳永逸了。

关于这个故事的详细内容可以看：https://wiki.eryajf.net/pages/1626.html#_2-%E7%BC%96%E8%AF%91%E6%9B%BF%E6%8D%A2%E6%B3%95%E3%80%82

故事二：mvn install 与 mvn clean install。

这个故事是在一个同事说他的项目代码更改了一些东西，但是发布之后发现好像并没有变化之后，引发的一系列深入探讨与试验，当时因为对比了一下编译流程，发现了只有在编译的时候差了一个 clean 的参数，因此就打算针对这个参数进行一些试验。

• 试验进行了三次，第一次是原始代码的试验，进行一次打包。
• 第二次试验的时候在代码里取消掉一个 jar 包的引用，然后用mvn install -Dmaven.test.skip=true的命令进行打包，发现打完包之后，代码里取消调用的那个 jar 包竟然依然存在。
• 第三次试验采用刚刚的代码（也就是取消那个 jar 包的调用），然后用mvn clean instal -Dmaven.test.skip=true的命令打包，发现打完包之后，代码里取消掉用的那个 jar 包也随之消失。

看完了这个试验之后，我们赶紧乖乖的在项目里都加入了 clean 的参数。

关于这个地方的详细探讨请看专业人士的专业文章：https://blog.csdn.net/abc86319253/article/details/44019881

故事三：编译的时候指定 maven 的配置文件

一般在公司里边，都会有自己搭建的私有仓库来作为 maven 的打包仓库，如果仓库的版本较新，那么一般可以与公网的远程仓库同步，如果仓库的版本略旧一些，那么就需要开发人员将项目中对应的依赖的 jar 包，传到私服当中来，一般情况下，项目编译的时候默认的就从内网的私服拉取 jar 包进行编译。

然而，有时候也会有另外的情况，那就是项目一开始就是用默认的远程仓库进行拉取依赖的，那么这个时候再使用内容的仓库进行编译，就会发生各种编译不过去的问题。这个时候，有两种解决方案，一个是依赖于 Jenkins 的 maven 风格进行配置文件的指定，还有一种就是直接在命令行里通过参数进行指定。

mvn clean install -gs /usr/local/maven/conf/settings1.xml -Dmaven.test.skip=true

其中 settings1.xml 是用的 maven 的默认配置文件，通过这条命令编译之后，一下子就完成啦。