Maven+Spring+MVC结构中，jetty/tomcat是如何启动项目的

针对maven配置的Spring+MVC项目，我们用Maven自带的jetty和tomcat插件进行调试，这很方便。但是调试时，这些插件所启动的web服务器，是如何来将我们的工程作为一个web项目启动并运行，可能并没有看上去那么简单。搞清楚它们启动时，是如何引用我们的项目，就是这的目的。

如果项目的名称是mvn_mvc，那么整个目录结构就如上图。

通常我们首先用mvn package生成上述的target目录中带红色部分。其等效执行 mvn compile test-compile test war:exploded war:war。也就是包含编译、测试和打包三步骤。接下来我们就可以使用mvn jetty:run或者mvn tomcat:run进行网站启动，测试运行了。此时会对应生成临时的jsp目录，jetty对应的目录名是work，tomcat对应的目录名是tomcat。

那么，项目对应的目录就是target/mvn_mvc目录吗？

非也非也！！！

真正的项目目录应该是：

1. 本项目的java类来自于target/classes
2. 本项目依赖的jar包来自于maven的pom配置(并没有实际的物理目录，为maven插件动态组织管理)
3. 本项目依赖的配置文件和静态资源来自于src/main/webapp
   

综上所述，可以得到两个结论就是：

• 运行时，其实和target/mvn_mvc这个目录（打包项目目录）没有任何关系。所以如果运行过程中如果修改了这个目录的动态class和静态文件，就看不到效果。必须改src/main/java和src/main/webapp的才行。
• 另外，maven设计的项目思想是：src目录下是纯本项目的代码，没有任何临时文件和依赖jar包。这样也便于代码的管理：自己写的是自己的，别人的机器的都放到别处
  

如果程序调试出现异常，就按照此方法检查。

譬如，再经过再一次的去maven大爷的痛苦经历后，终于明白了以前碰到的一个问题：

在调试过程中，发现弹出这么一个框，标题是obsolete methods on the stack。现象就是：更新的代码在调试中不起作用。

最后找到原因：不知道什么时候，在src/main/webapp/WEB_INF中出现了classes和lib目录。这会导致始终以这个目录的classes为源代码；和调试的我们的真正源代码java不一致。删掉它们才解决。