1.mvn clean不会clean掉本地已经install到repository的包，只是clean target里的内容；
2.Maven里的version如果是这种1.0.0-SANPSHOT，那这个SNAPSHOT的作用其实就是一个动态参数（类似动态获取当前时间），不过还需要<distributionManagement><snapshotRepository>配合，然后我们流水线构建后发布依赖到snapshotRepository仓库时如果是相同的版本（即都是1.0.0-SANPSHOT)，那么两次构建会在1.0.0-SNAPSHOT目录下生成两个jar包，它们都是以1.0.0-开头，后面会动态的根据构建时的时间来产生一个字符串；而当外部引用版本是1.0.0-SNAPSHOT包时就会找最近一次构建的；
3.对于idea项目（eclipse没测试，但是在同一个工作空间应该是一样的），如果一个项目里的module且也是maven项目，那么只需要添加dependency依赖项即可，不是必须将该module项目先install到本地repository；
只有当处于A项目的U module想要引用B项目的S module时，那么需要将B项目的module S进行install到本地repository里（但是注意，虽然在同一个项目【idea】/同一个工作空间【eclipse】里是不需要mvn install安装到本地仓库，但是如果用mvn package打包module，即便是同一个项目也需要被依赖的项目先mvn install才行）；
4.mvn clean失败可以看看是不是什么地方占用了target目录导致不能删除。
5.mvn package生成的jar包名一般是artifact+version，如果想指定一个名字，可以在plugin里添加<finalName>xx-service<finalName>，那么生成的就是xx-service.jar而不会由artifact和version作为前缀名
6.mvn执行maven命令默认用的是maven安装目录下的conf/settings.xml配置，但是可以通过mvn -s "..../settings.xml"来配置（IDEA里配置settings.xml文件路径其实就是通过-s参数实现的），idea里自带的maven插件里也是有conf/settings.xml文件的；
然后在settings.xml里有个<localRepository>配置mvn使用了这个settings.xml文件对应的maven仓库是哪个；
7.原来maven也支持配置依赖的区间version的方式，比如<version>[1.0.0, 2.0.0)</version>【不过它不会生成类似package-lock.json文件】，这个配置表示reimport时导入大于等于1.0.0，小于2.0.0的最新的版本依赖；如果是[1.1.0, 1.2.0)则是reimport时只导入依赖的1.1.x的最新版本（注意，依赖包有了新的符合条件的版本，必须是自己手动reimport才会更新）；
8.maven优先本地项目，然后才是maven仓库，即我们的pom.xml里的依赖如果是在同一个project里（idea，eclipse没测过），而且依赖写的不是本地路径就是普通的依赖添加方式（group，artifact，version），那么在idea的maven是会优先从同project的依赖项目添加的；举个栗子，A项目依赖B项目，A和B都在一个project里，然后B版本由1.0.0变成1.1.1，且还没有发布到中央仓库，那么此时A的仓库的依赖的B的配置由1.0.0改为1.1.1，然后reimport A项目，那么是会更新成功的（此时中央仓库没有B的1.1.1）