一、问题的出现
使用过java编译、打包的人都知道，maven库的重要：它可以帮我们存储内外部依赖供编译时使用，也可以在编译后存储我们的制品。可如此重要的maven库，却让笔者一度陷入了惆怅——只有一个maven库，有多个独立的仓库流水线运行，流水线之间编译时存在依赖。而每个仓库又有多个项目分支，分支间代码有差异甚至冲突，导致不能同时多个仓库多个分支流水线并发。可能说的有点晕菜了，让我们用一个图来说明：
如上图所示：B依赖于A，C依赖于A、B，D依赖于C。则编译顺序需要A—>B—>C—>D才能保证编译结果的正确性。可因为只有一个maven仓库，而代码具有多个项目分支，每个分之间的版本号又相同，且无法使用编排触发统一更改流水线分支号，导致了流水线无法同时运行多个项目分支。因为，一旦A、B、C、D指定运行branch1后，突然B改为运行branch2，则会导致C和D流水线编译报错，或制品异常。
可能有人会问：不能用编排方式A—>B—>C—>D统一触发？答案是“可以，但需要A、B、C、D的分支都要修改，无法自动修改”。听见这么一说，你可能会说：辣鸡。而我只能说：小朋友，社会上的事儿，少打听，事实就是如此。
正因为如此种种原因，导致笔者在多个项目并发时，需要反复切换多条流水线的分支号，且每次需要从头到尾编译，才能保证制品的正确性。
二、答案的呼之欲出
也许对于开发人员来讲，这个问题很好解啊。多建几个maven仓库呗，隔离一下就行了。嗯，答案挺好，下次别再说了。如果可以，为什么不呢？显然是因为有各种客观原因（比如使用的平台不允许），当然也有个人原因（不说了就是懒，不想再起新的）。既然如此，就别无他法了吗？显然不是。
既想用现成的平台，那么就得在他的规则圈中“自适应”。
制品隔离其实并不只有建多个maven库一条路——不同分支之间version区分、groupId或artifactId区分，也可以达到编译时引用指定代码分支的依赖和制品隔离的效果。
但是，有人说：仓库太多，一下子version区分有点难，用不同的groupId或artifactId区分有点麻烦……唉，既要这样，又不那样，怎么办呢？maven隔离一事又迫在眉睫，不然每次项目并发，都得花时间在流水线切换分支上，实在麻烦。
三、曲线救火也能行
思来想去，不就是不要侵入开发代码么？！那么……只要不改变开发代码，按照区分version、groupId或artifactId的方式，是不是一样可以达到maven隔离的效果？！
实践是检验真理的唯一标准，说干就干。
经过笔者更改和尝试，只用在编译时，修改groupId就行了，例如：增加项目分支后缀。如此，就可以在编译时，可以达到maven隔离的效果，如下图所示。
经过测试，的确如此。不同项目分支流水线，引用了maven库中不同分支路径的依赖，制品也进入了分支路径maven库。至此，困扰许久的maven隔离问题终于得到了解决。
四、尾声
在本案例中，笔者并没有侵入开发代码，只在编译环节做了groupId替换，如：将<groupId>xx.xx </groupId>替换为了<groupId>xx.xx.branch1</groupId>或<groupId>xx.xx.branch2</groupId>，让编译时到指定仓库分支路径下寻找需要的依赖，以及编译后将制品传至指定的仓库分支路径。
如果后续要做不同分支version区分呢？答案是：不影响。最多，我们将编译的groupId替换去除，你说是不是呢？
本文节选自第七十六期《51测试天地》
《从测试的角度，记一次maven仓库隔离的事儿》一文
想继续阅读全文或查看更多精彩内容，请点击下载：
