解决Maven项目相互依赖/循环依赖/双向依赖的问题
 
转自：https://blog.csdn.net/leolu007/article/details/53079875
添加新随笔很​多​时​候​随​着​项​目​的​膨​胀​，模​块​会​越​来​越​多​，如​果​设​计​上​ 稍​有​不​慎​就​会​出​现​模​块​之​间​相​互​依​赖​的​情​况​。​这​对​于​使​用​Maven的​用​户​是​比​较​痛​苦​的​，因​为​出​现​模​块​之​间​相​互​依​赖​的​话​在​构​建​的​时​候​就​会​失​败​，Maven通​常​要​先​编​译​被​依​赖​的​模​块​，如​果​出​现​相​互​依​赖​Maven就​不​知​道​该​怎​么​办​了​。​下​图​描​述​了​三​个​Maven模​块​相​互​依​赖​的​场​景​:  

 图 1. A、​B、​C三​个​模​块​相​互​依​赖​ 
 

 图​中​模​块​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 
 1. 使​用​build-helper-maven-plugin解​决​相​互​依​赖​的​问​题​我​的​解​决​办​法​就​是​先​把​相​互​依​赖​的​模​块​整​合​在​一​起​，相​当​于​把​这​些​模​块​合​并​成​一​个​单​独​的​模​块​统​一​编​译​， 
 如​下​图​：图 2. 合​并​A、​B、​C三​个​模​块​为​D模​块​ 
 

 这​样​就​产​生​了​一​个​合​并​模​块​D，我​们​把​它​当​做​一​个​辅​助​构​建​模​块​，然​后​让​A、​B、​C模​块​都​依​赖​于​D模​块​，这​样​的​话​就​可​以​成​功​编​译​A、​B和​C模​块​， 
 如​下​图​： 图 3. 基​于​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模​型​  
Java代码  
 
  
<project xmlns="http://maven.apache.org/POM/4.0.0"  
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"  
    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">  
    <parent>  
        <groupId>org.kuuyee.sample</groupId>  
        <artifactId>sample-parent</artifactId>  
        <version>1.0-SNAPSHOT</version>  
        <relativePath>../../pom.xml</relativePath>  
    </parent>  
    <modelVersion>4.0.0</modelVersion>  
    <groupId>org.kuuyee.sample</groupId>  
    <artifactId>module-D</artifactId>  
    <version>1.0-SNAPSHOT</version>  
    <packaging>jar</packaging>  
    <name>module-D</name>  
    <url>http://maven.apache.org</url>  
    <properties>  
        <project.build.sourceEncoding>  
            UTF-8  
        </project.build.sourceEncoding>  
        <module.a.src>../../module/module-A/src/main/java</module.a.src>  
        <module.b.src>../../module/module-B/src/main/java</module.b.src>  
        <module.c.src>../../module/module-C/src/main/java</module.c.src>  
    </properties>  
    <build>  
        <plugins><!-- 解决模块相互依赖,综合所有相互依赖代码统一编译 -->  
            <plugin>  
                <groupId>org.codehaus.mojo</groupId>  
                <artifactId>build-helper-maven-plugin</artifactId>  
                <executions>  
                    <execution>  
                        <id>add-source</id>  
                        <phase>generate-sources</phase>  
                        <goals>  
                            <goal>add-source</goal>  
                        </goals>  
                        <configuration>  
                            <sources>  
                                <source>${module.a.src}</source>  
                                <source>${module.b.src}</source>  
                                <source>${module.c.src}</source>  
                            </sources>  
                        </configuration>  
                    </execution>  
                </executions>  
            </plugin>  
        </plugins>  
    </build>  
    <dependencies>  
        <dependency>  
            <groupId>junit</groupId>  
            <artifactId>junit</artifactId>  
            <version>3.8.1</version>  
            <scope>test</scope>  
        </dependency>  
    </dependencies>  
</project>  

【转载地址】http://www.blogjava.net/kuuyee/archive/2011/06/28/353158.html 

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，也可以消除循环依赖 
 　　 
 　　这两种重构方式都是可行的，具体采用哪种方式要根据实际情况来判断。不管采取哪种方式，都需要对代码进行修改，有时候并不是那么容易的

问题：
 
 
 
操作系统适配器层的适配器子系统需要向框架层发送键盘或者鼠标消息，c++代码如何发送这一类消息呢？让适配器子系统调用框架层的一个函数？这样一来操作系统适配器子系统必须依赖于框架层了，违背了每一层只能依赖于下面一层的原则。
 
 
一个想法：让适配器子系统层和框架层双向依赖？
 

 
 
双向依赖的问题：强双向依赖和若双向依赖
 
 
 
强双向依赖：即在父亲类中聚合了一个孩子，而孩子类中有聚合一个父亲，首这种强双向依赖的关系不仅在现实世界根本不存在，在面向对象世界也不可能存在：“父亲有一个孩子，孩子有一个父亲”涉及到了两个命题，一个是因，一个是果，它们不能互为因果，在面向对象世界里，互为因果的代码则无法通过编译；
 
 
 
 
头文件互相循环嵌入的代码也无法通过编译，这种情况类似于进程之间的死锁问题，编译器想要成功地编译父亲类，就会要求孩子类在父亲类之前被定义，而孩子类有要求父亲类咸鱼孩子类被定义---显然是自相矛盾的事情
 
 
在C++语言，如果一定要实现双向依赖，那么至少有个一个方向的关系必须使用指针实现的若依赖关系；如果类A的头文件中只定义了类B的一个指针，没有使用类B中的任何属性和方法，C++编译器就不要求类B在类A之前被定义了，但是仍然要告诉编译器代码中存在一个名为B的一个类
 
 
 
 
因为双向依赖对系统结构会造成软件代码之间，组件之间，包或者子系统之间的强烈耦合，对于需要适应不同需求和不同平台的系统，当相互依赖的两个包之间，任何一个包的接口发生变化，另外一个包就要相应地进行修改双向依赖使得操作系统的可扩展性，灵活性和可复用性荡然无存了，操作系统适配器层本身就是一个需要适应不同操作系统平台的软件层次，如果因为应用框架层的修改而导致了这一层的修改不是我们需要看到的，所以双向依赖这种方案不应该采用
 

在使用spring data jpa 的过程中，有时候会有双向依赖的需求，如查询班级时需要级联查出班级内所有的学生，查询学生时需要查询学生所在的班级。体现在代码中便是
 
public class ClassOne implements Serializable{

    private static final long serialVersionUID = -15535318388014800L;

    private Long id;

    private String className;

    @OneToMany(mappedBy = "class", fetch = FetchType.LAZY)
    private Set<Student> students;

}

public class Student implements Serializable{

    private static final long serialVersionUID = -15535318388014800L;

    private Long id;

    private String studentName;

    @ManyToOne(cascade = CascadeType.ALL, fetch = FetchType.LAZY)
    @JoinColumn(name = "class_id")
    private ClassOne class;

}
 
这种情况在查询序列化的过程中，一端加载多端，多端有依赖一段，就会造成死循环的现象出现。解决这个问题通常由三种方法。
 
1. 使用DTO对象，查询出信息后使用DTO对象进行封装，最后传给前台，在序列化之前将依赖关系去除掉。
 
2.使用@JsonIgnore注解，在关联对象上添加这个注解，使在序列化是忽略掉这个字段。但是同时关联的对象也不会在josn数据中出现。
 
3.@JsonIgnoreProperties注解，这个注解可以选择性的忽略固定字段，也就是说可以在查询班级的时候，忽略掉班级所级联出来的学生的班级字段，从而避免死循环。这个方法技能解决死循环，又能将级联到的数据返回到json。
 
public class ClassOne implements Serializable{

    private static final long serialVersionUID = -15535318388014800L;

    private Long id;

    private String className;

    @JsonIgnoreProperties({"class"})
    @OneToMany(mappedBy = "class", fetch = FetchType.LAZY)
    private Set<Student> students;

}

public class Student implements Serializable{

    private static final long serialVersionUID = -15535318388014800L;

    private Long id;

    private String studentName;

    @ManyToOne(cascade = CascadeType.ALL, fetch = FetchType.LAZY)
    @JoinColumn(name = "class_id")
    @JsonIgnoreProperties({"students"})
    private ClassOne class;

}
 
 

重构 — 改善既有的类图设计
条款1：将双向依赖改变成单向依赖




黄国强 2008/5/6



把这个条款放在第一个，是因为我认为，把设计中的所有双向依赖关系排除掉，是进行下一步重构工作的前提。




 

 图1
 

 

 如图1所有，图中有两个类，他们之间存在双向依赖关系。存在着两条箭头。这个图是用 Visio 画的。箭头从类 A 指向 B 表示 A 依赖于B。

 

 图2
 

 

 图中表现了将图1中的类图变成单向依赖的两个方法，具体设计中可以根据您的具体领域的情况选择其一。

简单解释一下。

方法1：

这里新增了一个类 C ，如果 B 需要将消息发送给 A ，只需要向 C 发送一个消息即可，A 定时检查 C 的状态，如果发现 C 的状态显示 B 有新的消息，A 就去到 B 中去查询。

方法2:

A 与 C 的关系更紧密，A 与 C 是继承关系。虽然在设计模块之间关系过紧并不好，但是这个方法比方法一的优势在于 B 向 C 发送消息， A 马上就能收到，A 无需写一个定期查询的函数。