今天完成的事情：

1、测试一个RMI服务，

现在我想把一个 studentService 分离为rmi服务。

在原有的项目中，如果作为服务端的studentService和其实现类studentServiceImpl 不在同一个项目中的话。

在客户端运行作为代理bean的studentService时，会报 connectionRefused 错误。

2、学习并配置nginx跨域。

3、尝试解决maven冲突。
明天计划的事情：

1、申请进复盘项目。 
遇到的问题：

1、公司的自动代码生成项目：commons-code-demo 的 ExcelDocTest 类的main方法、在运行时依然会报错。

百度了一下之后，我觉得这可能是 maven 依赖冲突所产生问题、但我又对什么是 jar 包冲突没啥概念。

http://blog.csdn.net/ksgt00016758/article/details/26680233

找了一个教程学习如何解决 maven 依赖冲突。

首先从下载demo。

这个demo演示了由于maven的“最近获胜策略（nearest wins strategy）”所导致的冲突。

如上图所示，现在有一个web应用reslove-web，

该工程依赖于project-A 和 project-B，

——project-A依赖于project-common的1.0版本并调用其中的sayHello()方法。

——project-B依赖于project-C，

————而project-C又进一步依赖于project-common的2.0版本并调用其中的sayGoodBye()方法。

project-common的1.0和2.0版本是不同的，1.0中包含sayHello()方法。

而2.0中包含了sayHello()和sayGoodBye()两个方法。

下载demo之后，必须根据依赖关系、依次执行mvn install生成所有工程的jar包。

①

project-common的项目只有一份。如何使它产生1.0和2.0两个版本的jar包呢？

在project-common目录下运行“mvn clean install”后会生成1.0的jar包。

之后代码中添加一个sayGoodBye方法、到pom中将版本改为2.0、再次运行“mvn clean install”。

便生成了2.0包。

此时去本地仓库会发现project-common 有了1.0和2.0的jar包。

②

然后依次对project-A，project-c，project-B执行install命令。

现在我们查看一下idea生成的maven依赖图：

可以明显看到project-C项目与它所依赖的project-common 2.0 由一条红线连接，且2.0版本上又有一条红虚线指向了project-common 1.0上。(红线可不是我画的)

此时我们在resolve-web根目录执行

mvn clean verify org.codehaus.cargo:cargo-maven2-plugin:run

使这个web项目在web容器中跑起来，我们打开“localhost:8080/resolve-web/hello”，

----------------------------------------------------------------------------------------------------------------------------

再打开“localhost:8080/resolve-web/goodBye”，报错：NoSuchMethodError。

所以，resolve-web分明引用的有goodbye方法的project-common 2.0、在最终执行时却报错没有这个方法、引用了1.0的版本。

如何解决呢？办法一：

在resolve-web中加入对project-c 2.0的依赖。

<dependency>

     <groupId>project-common</groupId>

     <artifactId>project-commmon</artifactId>

     <version>2.0</version>

   </dependency>

在resolve-web直接加入 对project-c 2.0的依赖 后，maven依赖图也发生了变化。

办法二：
esolve-web对project-A的dependency声明中，将project-common排除掉。在resolve-web的pom.xml文件中修改对project-A的dependency声明。

现在貌似是把maven冲突是怎么回事给搞明白了。

再回到common-code-demo项目，打开它的maven依赖图，发现是这样的。

看的眼花，需要再花点时间研究。

收获：

1、又掌握了一点maven的规律。