maven多模块项目jetty插件的热部署

>>>>>maven多模块项目jetty插件的热部署
适用于(类似如下结构)：
prarent_demo
       moduleA has a class named classA
       moduleB has a class named classB
       module_web depend on moduleA,moduleB

一般默认jetty部署module_web时，项目的结构
module_web
      classes
         actionA.class
         otherAction.class
      src
         {web sources}
      lib
          moduleA.jar 该jar包的物理地址在maven的本地repository
          moudleB.jar 同上
          otherJar

插入一点maven项目编译的知识：
      当你在moduleA或者moduleB修改java源代码后，其编译(eclipse默认是开启保存自动编译的)的class
文件放在${projectDir}/target/classes文件夹下。

现在再来看jetty默认部署情况下类的加载：
1.当actionA调用classA时，jetty容器会加载moduleA.jar下面的classA.class。
2.当你测试发现classA的逻辑有问题后，更改classA.java的源代码。

3.此时${projectDir}/target/classes/下的classA.class已经是
最新修改后的编译结果，而${mavenRepository}/moduleA.jar并没有任何更新

4.所以你不得不在moduleA上运行类似“mvn install”这样的命令，install既是
将项目打好的包安装到maven仓库。此时${mavenRepository}/moduleA.jar已更新

5.此时你重启web容器方能看到刚刚修改的特性

所以jetty热部署的解决方案是：
       将原本需要从${mavenRepository}/moduleA.jar里面加载classA 直接更改为
从${projectDir}/target/classes/下面加载。

jetty-maven插件的具体配置：

读懂上述配置需要理解maven构建时插件的配置，此处略。
1.热部署最核心的部分就是红框1所标出的那一块，<extraClasspath>标签从在面意思上也很容易理解，不必赘述。
2.红框2标出的两块一般是配合使用。下面配置的是需要定时扫描的对象，上面配置的是扫秒时间间隔，及重启策略。
热部署码，当然是监控到源码自动重新加载才叫热部署嘛，所以红框2一般情况下也是需要的。

      但可以看到我把reload的属性值为manual了，意思是手动。也就是scanTarget标签是没有任何作用的。这里是我
根据具体项目决定的，我也推荐使用manual，需要reload时只需在console中键入换行回车符。 因为web项目依赖比较多，
而大部分情况下，需要修改的不止一个项目， 热部署的话可能会造成频繁重启，造成内存溢出等问题。还有一个就是
自动重启会多次重启的问题。

其他注意事项：
      1.红框1中<extraClasspath>标签对应的接口是webAppConfig的配置，貌似是servlet的api？？因此几乎所有web容器都能
配置，jetty作为web容器也不例外，但相应的也是jetty文档中未提到此项配置的原因。
      2.<extraClasspath>里面的 用绝对路径也是可以的应该。
     3.特别注意，如此配置，并没有去掉对web服务对${mavenRepository}/moduleA.jar的依赖，也就是理论上同时包含了两个classA.class
类，实践中容器加载的总是 ../target/classes下面的，最新的那个class,应此一般情况下是可行的。 这两天我spring集成dubbo时，老是
出现duplicate bean id的错误，原因就在于容器将 /target/classes和仓库jar包下的配置文件都加载了，在纯spring中，
spring默认如何bean id相同则覆盖的，但是dubbo会报错，此时你只要保证相关配置文件只要被加载一次就ok了。 如果你用热部署也出现类
似问题，从这方面下手。