最近开发一个半成品的社区商城小程序的项目。项目使用的是nacos微服务,使用过程中常常会模块依赖冲突。
如图所示:在订单成功之后我需要在订单支付回调中指定派送。而在派送员模块中需要调用查询订单等诸多方法 这时候就会出现maven模块依赖问题
后面再网上查问题时碰到的方案,以下内容部分转自:https://www.iteye.com/blog/hck-1728329l
很多时候随着项目的膨胀,模块会越来越多,如果设计上 稍有不慎就会出现模块之间相互依赖的情况。这对于使用Maven的用户是比较痛苦的,因为出现模块之间相互依赖的话在构建的时候就会失败,Maven通常要先编译被依赖的模块,如果出现相互依赖Maven就不知道该怎么办了。下图描述了三个Maven模块相互依赖的场景:
图中模块C依赖于模块B,模块B依赖于模块A,而模块A又依赖于模块C,这样就出现了相互依赖情况,如果运行mvn compile会出现如下错误:
[INFO] Scanning for projects… [ERROR] The projects in the reactor contain a cyclic reference: Edge between ‘Ve rtex{label=‘org.kuuyee.sample:module-C:1.0-SNAPSHOT’}’ and ‘Vertex{label=‘org.ku uyee.sample:module-B:1.0-SNAPSHOT’}’ introduces to cycle in the graph org.kuuyee .sample:module-B:1.0-SNAPSHOT --> org.kuuyee.sample:module-A:1.0-SNAPSHOT --> or g.kuuyee.sample:module-C:1.0-SNAPSHOT --> org.kuuyee.sample:module-B:1.0-SNAPSHO T -> [Help 1][ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e swit ch.[ERROR] Re-run Maven using the -X switch to enable full debug logging.[ERROR] [ERROR] For more information about the errors and possible solutions, please rea d the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/ProjectCycleEx ception
使用build-helper-maven-plugin解决相互依赖的问题我的解决办法就是先把相互依赖的模块整合在一起,相当于把这些模块合并成一个单独的模块统一编译
这样就产生了一个合并模块D,我们把它当做一个辅助构建模块,然后让A、B、C模块都依赖于D模块,这样的话就可以成功编译A、B和C模块,
要想把A、B、C三个模块整合在一起编译,需要借助build-helper-maven-plugin插件,这个插件在Maven构建周期提供一些辅助功能,下面列出插件的提供的功能列表: build-helper:add-source:添加更多的构建源码目录 build-helper:add-test-source:添加更多的测试源码目录 build-helper:add-resource:添加更多的资源目录 build-helper:add-test-resource:添加更多的测试资源目录 build-helper:attach-artifact:在安装和部署周期附加artifacts build-helper:maven-version:添加一个指定当前Maven版本的属性 build-helper:parse-version:添加一个指定组件版本的属性 build-helper:released-version:决定当前项目的最终版本 build-helper:remove-project-artifact:从本地资源库中移除项目的artifacts build-helper:reserve-network-port:Reserve a list of random and unused network ports. 在这里我们要用到build-helper:add-source这个功能,将模块A、B、C的源码路径加进来。 我们再添加一个辅助模块D,在辅助模块D中使用build-helper-maven-plugin插件,然后让模块A、B、C都依赖于辅助模块D,模块D的POM模型如下: 例 1. 辅助模块D的POM模型
找到灵感之后,在代码中做了如下的改造
新建中间模块depend,并且加了一个IOrderDeliverStatusService接口,接口内容如下:
/**
* 配送员订单服务类
*
* @author BladeX
* @since 2020-12-11
*/
public interface IOrderDeliverStatusService extends BaseService<OrderDeliver> {
/**
* 派单
*
* @param orderSn
* @return
*/
boolean assignOrder(String orderSn);
}
定义了订单模块中需要调用的配送模块的方法。而后在deliver中新建实现类 继承service接口
@Service
public class OrderDeliverStatusServiceImpl extends BaseServiceImpl<OrderDeliverMapper, OrderDeliver>
implements IOrderDeliverStatusService {
@Override
public boolean assignOrder(String orderSn) {
//业务代码
}
}
order模块中直接引入depend依赖即可调用assignOrder方法
maven处理循环依赖
在多maven工程的项目里,如果工程间存在循环依赖,构建就会报错。本文介绍一下循环依赖要怎么处理
1、什么是循环依赖
如果工程A依赖工程B,工程B又依赖工程A,就会形成循环依赖。或者A依赖B,B依赖C,C依赖A,也是循环依赖
总的来说,在画出工程依赖图之后,如果发现工程间的依赖连线形成了一个有向循环图,则说明有循环依赖的现象
如果循环依赖发生在工程之间,则会影响构建,因为maven不知道应该先编译哪个工程。如果循环依赖发生在同一个工程的模块之间,虽然不影响编译,但是也是一种不好的实践,说明模块的设计有问题,应该避免
如果在模块内部,有几个类互相调用的话,我觉得可能是正常的。比如观察者模式里面,Observer和Observable就是互相依赖的
2、怎么解决循环依赖
目前知道有2个办法可以解决
第一个办法是用build-helper-maven-plugin插件来规避。比如A依赖B,B依赖C,C依赖A的情况。这个插件提供了一种规避措施,即临时地将工程A、B、C合并成一个中间工程,编译出临时的模块D。然后A、B、C再分别依赖临时模块D进行编译
这种方法可以解决无法构建的问题,但是只是一个规避措施,工程的依赖关系依然是混乱的
第二个办法是通过重构,从根本上消除循环依赖
3、如何重构
目前也知道2个重构的思路
第一个办法是平移,比如A和B互相依赖,那么可以将B依赖A的那部分代码,移动到工程B中,这样一来,B就不需要继续依赖A,只要A依赖B就可以了,从而消除循环依赖
第二个办法是下移,比如A和B互相依赖,同时它们都依赖C,那么可以将B和A相互依赖的那部分代码,移动到工程C里,这样一来,A和B相互之间都不依赖,只继续依赖C,也可以消除循环依赖
这两种重构方式都是可行的,具体采用哪种方式要根据实际情况来判断。不管采取哪种方式,都需要对代码进行修改,有时候并不是那么容易的
新人博客,写的不好望见谅!