【转载备】更新整个maven工程及相关底层并再运行的记录

前言：本例我们的需求其实只是改一个SQL，从昨天上午开始工作，直到昨晚下班前才搞定。只是一个SQL，而且只是加了个条件。

整了一天，这么长的时间只解决了一个这，需要好好反思下。接下来对12月22日这不堪回首的一天进行简单记录。 

 

1.【修改SQL】

本例的需求是修改SQL，所以先说在修改中遇到的问题。

就一个问题：字段名的问题。

修改过的SQL多了一个选择的条件，还修改了很多选择出来的字段的自定义名。

报的错就是，另外一个SQL使用的时候提示不存在某字段。后来更改到和以前一样就OK了。

所以自定义字段名虽然对本SQL的运行没有影响，但放到整个项目中，自定义名可能在别的地方用到了。即，可以根据需求修改自定义名！

因为，不会对功能造成影响。

 

【修改的技巧】

这里提一点修改的技巧问题。我们修改代码，特别是SQL的时候，往往变动不会太大。

所以执行Team与资源库同步的操作，会知道自己改了哪儿。比较清晰。

话说回来了，修改修改，对比原来的东西进行修改，本来就理所当然。

盲目的复制粘贴不是正常人修改的逻辑，就跟改病句一样，也是看着原来的进行修改。哪有看一遍就删掉去修改的，是不是傻！

 

2. 【更新工程】

【更新的必要】

蓝后台的工程很久没有用过了，所以需要更新。

本工程，以及相关底层，都需要更新。

这里提出一个需要注意的地方：【注意】更改工程的时候，先要更新！一定！先要更新！

【更新的过程】

此次我们脑子抽了，先把蓝后台的整个工程更新了！其实没有必要，只需要更新SQL-MAP就可以了。

嘛，也没事，以后也省点事儿。其实，讲真，虽然每次更改前更新整个工程并没有必要，但还是需要定时更新一下的。

接下来说更新整个工程的过程以及遇到的问题。

第一步：更新本工程即相关底层的工程

右键本工程相关的所有项目，Team选择更新。

第二步：对底层进行clean以及打包。

maven工程依赖了很多底层项目。这些底层项目是我们的主项目的基础。

更新以后，还需要将所有的这些底层项目进行maven clean然后再maven install。

maven clean：该操作的效果是清楚项目target目录下的所有文件。

maven install：该操作是将本项目进行重新打包。

第三步：对主项目重新build。

底层项目的maven install是将它自己打包，主项目的maven build是把自己的依赖项目打的包引进来，然后再把自己打包。

其实我们在maven build的命令下也填的是：clean install。

是不是也能理解为先maven clean清楚target目录文件，然后再重新打包？！有待后续研究。

 

3.【工程跑不起来】

将所有的更新工作做完以后，我们遇到的第一个问题就是工程跑不起来。

直接进入localhost:8080/ngtradebackend，马上就会报错。即，工程没有跑起来。

虽然Tomcat部署了，服务器也跑起来了。但是部署在服务器上的主工程却运行不起来。

 

【Tomcat上的工程运行起来的逻辑】

工程运行不起来，我们研究了工程正常运行起来的逻辑，工程能够正常运行起来，经历了一个什么过程。

1. 【工程没有问题】

当然，首要一步，工程要没有任何问题。这个可以保证，毕竟是线上的代码，有问题的可能性还是比较小的。

2. 【工程的正常运行逻辑】

工程，Java项目，为什么能够正常运行起来呢？一行一行可以在记事本打开看到的代码，为什么能够运行起来供我们使用呢？

这最基本的逻辑，因为长久以来，Eclipse自动帮我们做了很多，有些是通过不知道什么意思的指令或者菜单选项，有些是默认就帮我们做了。因为帮我们做了，所以连最基本的逻辑都忘了去研究。都忘了Eclipse只是一个编程的帮助工具而已。

【回顾HelloWorld】

我们可以去回顾一下，我们的Hello World！第一个Java项目运行的时候。

最原始的命令行运行的时候，执行了一些怎样的指令才成功运行的。

（想当初在学校的机房里只是照着PPT做，也没想是为什么就运行起来了，现在回过头去看最基础的东西。本来在HelloWorld的时候就应该明白的东西。）

JDK安装和环境变量的配置就略过了。我们只说代码诞生之后如何运行。这里假设，HelloWorld的Java代码在 D:\JAVA 下。

进入命令行窗口。

首先，切换到HelloWorld的代码目录下。

然后，输入javac HelloWorld.java，调用编译指令javac把HelloWorld.java转换为字节码文件HelloWorld.class。

最后，敲入命令java HelloWorld。就可以运行程序了，实际上是：代码转换为.class 文件后在JVM虚拟机下运行了。

 

回顾了如上过程我们就可以知道，java代码要运行，需要转为字节码文件.class，然后才能够放在JVM虚拟机下运行。

 

【反观Eclipse运行大型WEB项目的逻辑】

大型的WEB项目，当然不只是打印些什么东西出来。它需要调用数据库，需要引用别的工程，需要引用底层项目的jar包，还需要连接数据库，还需要能够接收数据并处理。要做的事情实在太多了。但其核心还是一个java项目，java web项目。最主要的也还是一堆.java的代码。这一堆.java 的代码也还是需要转为.class的字节码文件，才能够成功运行。

但现在的这种项目又不同于以前的纯java项目，只需要在Eclipse的工具栏中点Run就能运行的那种。

现在的web项目，需要部署在Tomcat服务器上，才能够成功运行。

Tomcat，也不是java web项目诞生的时候，它就诞生了。百科的解释是：Tomcat是Apache 软件基金会（Apache Software Foundation）的Jakarta 项目中的一个核心项目，由Apache、Sun 和其他一些公司及个人共同开发而成。

所以，Tomcat也只不过是帮助web项目运行的一个工具罢了。

而Tomcat服务器做的事情又是什么呢？

查到的资料显示，Tomcat服务于B/S架构，即Browser/Server，浏览器/服务器模式。（与之对应的是C/S架构，即Client/Server，客户端/服务器模式。）

当然了，Tomcat是web服务器，肯定是B/S架构。废话，不然为什么叫web服务器！

我们以前运行普通的java项目的时候，不需要Tomcat服务器，为什么，因为不是web项目。只有是web项目才需要用到它。

为什么，web项目有什么特殊的地方？

web项目，所谓web项目，实际上运行起来是一个网站。这个网站为什么可以被访问，如何被访问？

通过链接进行访问的啊。为什么你可以通过链接进行访问呢？

那是因为这个web项目部署在了web服务器上。

我们需要什么才能够访问网站呢？网络，网络又是什么？万维网！

万维网的本质是什么？万维网的本质是"超文本文档"（HTML文档）组成的一个通过超级链接互相访问交互网络。

我们通过www.blabla.com去访问网站。却不知道只有将网站的web项目放到web服务器中才能够访问。

但是Tomcat作为一个web服务器，当然还有别的功能。

在论坛里看到这样的回答，TOMCAT，Apache 开发的一个 Servlet/JSP 容器，主要是解析和运行JSP。

对的，我们回想刚接触JSP的时候，如何才能看到效果？run on server对不？

这个server就是Tomcat服务器。

即，Tomcat服务器的作用是，包含了web项目，解析运行网站除了java代码的其他代码如JSP，这样别人才可以正常的访问网站。

 

但，web项目是由java代码和不是java的代码组成的。不是java的代码由Tomcat服务器解析和运行，是java的代码呢？

当然应该先转换成.class文件，然后才能够运行。所以Tomcat服务器上，肯定要有.class的字节码文件。

这些字节码文件来自于java代码的编译结果。

我们在Eclipse中运行web项目的时候，右键run on server就可以了。整个过程要等一段时间才能跑起来。

这个过程中，Eclipse在做什么？Tomcat在做什么呢？

细想就能知道一些了，Eclipse肯定会把web项目中的java代码转换成.class的字节码文件。也肯定会把这些字节码文件，还有不是java的代码如jsp等，放到Tomcat中去。

这样Tomcat运行的时候，才能把所有的代码跑起来。

再次回想一下最初的bbs项目，我们在提交代码的时候，为什么不需要提交build文件夹，因为build文件夹中是编译后的产物。

其中只有.class文件，这些文件于实际检查中是没有用的，只有在运行的时候才有用。所以可以随时删除，因为运行的时候，Eclipse会自动再帮我们生成一次。

因为要运行啊。

而maven项目的工程结构是什么呢？项目刚进去的根目录最主要的就是三个：src文件夹、target文件夹、pom文件。

pom文件抛开先不说。

src里是源代码，点进去发现只有一个main文件夹，再点进去就是三个文件夹：java、resources、webapp。

java里是java代码。当然也不只是有java代码，还会有SQL-MAP文件，说白了就是那一堆com.xxx.common之类的包下面的代码。

resources下面是一堆配置文件。比如sql-map-config.xml、module.properties等。

webapp里就是我们需要用到的一些资源文件了。资源文件不放在名为resources的文件夹下还真是奇怪呢！这个webapp中的资源文件就是jsp、js、css文件还有一堆图片什么的。比较重要的还有一个名为WEB-INF的文件夹，顾名思义，就是web信息的文件夹。其中有web.xml还有controller-action-config.xml。最原始的bbs项目中我们记得只有一个web.xml。其中的代码为了以示重视贴出来：

[html] view plain copy

1. <?xml version="1.0" encoding="UTF-8"?>  
2. <web-app version="2.5" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"  
3.   xsi:schemaLocation="http://java.sun.com/xml/ns/javaee   
4.     http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd">  
5.   <display-name>web_dj_ngtrade_backend</display-name>  
6.   <servlet>  
7.     <servlet-name>action</servlet-name>  
8.     <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>  
9.     <init-param>  
10.       <param-name>contextConfigLocation</param-name>  
11.       <param-value>classpath:sql-map-config.xml,classpath:mission-sql-map-config.xml,classpath:point-sql-map-config.xml,classpath:query-sql-map-config.xml,classpath:data.xml,classpath:dao.xml,classpath:service.xml,/WEB-INF/controller-action-config.xml,/WEB-INF/rmi.xml,/WEB-INF/upload-servlet.xml,classpath:jms-beans.xml</param-value>  
12.     </init-param>  
13.     <load-on-startup>1</load-on-startup>  
14.   </servlet>  
15.   <servlet-mapping>  
16.     <servlet-name>action</servlet-name>  
17.     <url-pattern>*.html</url-pattern>  
18.   </servlet-mapping>  
19.   <session-config>  
20.     <session-timeout>180</session-timeout>  
21.   </session-config>  
22.   <listener>  
23.     <listener-class>  
24.       com.downjoy.app.ngtradebackend.common.web.SessionListener  
25.     </listener-class>  
26.   </listener>  
27.   <filter>  
28.     <filter-name>Filter1</filter-name>  
29.     <filter-class>com.downjoy.app.ngtradebackend.common.web.MyFilter</filter-class>  
30.   </filter>  
31.   <filter-mapping>  
32.     <filter-name>Filter1</filter-name>  
33.     <url-pattern>/*</url-pattern>  
34.   </filter-mapping>  
35.   <welcome-file-list>  
36.     <welcome-file>/jsp/login.jsp</welcome-file>  
37.   </welcome-file-list>  
38. </web-app>  

其中最大的标签是web-app，定义web应用中的一些东西呗！

具体定义了四个东西。servlet、servlet mapping（怎么访问之类的，如.html）、listener监听器还有欢迎界面welcome-file-list。

源码中定义了这以上所有东西不可谓不完备。只是最后的web.xml文件，这么重要的文件却要放在不怎么会去关注的webapp放资源文件的文件夹里。而名为资源resources的文件夹里放的却是连接数据库之类的配置文件，太奇怪了！

最后就只剩target文件夹了。

只剩它了，想想就大约能感觉到。这个文件夹里放的是.class的字节码文件，还放了不是java代码的一堆东西，总之，把这个文件夹放到Tomcat服务器中，便能够将整个web工程跑起来了吧。

果然，点进去就有个class文件夹，还有另外一个文件夹，名字与项目名相同。另外还有一个本项目的war包。

原来源码中的java、resources、webapp三个核心文件夹变成了两个。一个class、一个项目名文件夹。

按理来说，比较正常的转换方式是----按原来的项目结构，只把java代码转为.class的字节码文件，其他的保持原来的结构就可以了。这里居然变了。

去看一下，发现class文件夹里除了java文件夹中的.java转过来的.class文件，还有原resources文件夹中为数不多的一些配置文件。也就是把java和resources文件夹合并为了

一个class文件夹。项目名文件夹中装着的，是原来webapp文件夹中的资源文件，即jsp、js、css文件还有一堆图片什么的。

这种建文件夹的方式也是奇怪，不过也许是为了往Tomcat上部署的时候，方便吧。。。。

既然知道了target中是什么东西。下一步，我们去看一下Eclipse中Tomcat的部署目录。看那里有些什么东西吧？

Tomcat的部署目录我们需要看的是这个文件夹-----E:\myworkspace\.metadata\.plugins\org.eclipse.wst.server.core

这个名为org.eclipse.wst.server.core。意思是：Eclipse下的服务器的核心文件夹。

这个文件夹的结构如下：

可以看到，建了几个服务器，就有几个tmp的文件夹。每个tmp就是一个服务器。除了这些文件夹，还有servers.xml文件。我们之前修改过服务器的启动时间，就是在这个名为server.xml的文件中修改的。它的代码如下：

[html] view plain copy

1. <?xml version="1.0" encoding="UTF-8"?><servers>  
2.   <server auto-publish-setting="2" auto-publish-time="1" configuration-id="/Servers/Tomcat v6.0 Server at localhost-config" deployDir="wtpwebapps" hostname="localhost" id="Tomcat v6.0 Server at localhost" name="alpha" runtime-id="Apache Tomcat v6.0" server-type="org.eclipse.jst.server.tomcat.60" server-type-id="org.eclipse.jst.server.tomcat.60" start-timeout="45" stop-timeout="15" testEnvironment="true" timestamp="14">  
3.     <list key="modules" value0="9_16_1016_springmvcframeworkconstruct::org.eclipse.jst.jee.server:9_16_1016_springmvcframeworkconstruct::jst.web::2.5"/>  
4.   </server>  
5.   <server auto-publish-setting="2" auto-publish-time="1" configuration-id="/Servers/Tomcat v6.0 Server at localhost (2)-config" deployDir="wtpwebapps" hostname="localhost" id="Tomcat v6.0 Server at localhost (2)" name="data_backend" runtime-id="Apache Tomcat v6.0" server-type="org.eclipse.jst.server.tomcat.60" server-type-id="org.eclipse.jst.server.tomcat.60" start-timeout="45" stop-timeout="15" testEnvironment="true" timestamp="3">  
6.     <list key="modules" value0="web_moyoyo_data_backend::org.eclipse.jst.jee.server:web_moyoyo_data_backend::jst.web::2.5"/>  
7.   </server>  
8.   <server auto-publish-setting="2" auto-publish-time="1" configuration-id="/Servers/Tomcat v6.0 Server at localhost (3)-config" deployDir="wtpwebapps" hostname="localhost" id="Tomcat v6.0 Server at localhost (3)" name="ngtrade_backend_8080" runtime-id="Apache Tomcat v6.0" server-type="org.eclipse.jst.server.tomcat.60" server-type-id="org.eclipse.jst.server.tomcat.60" start-timeout="45" stop-timeout="15" testEnvironment="true" timestamp="4">  
9.     <list key="modules" value0="web_moyoyo_ngtrade_backend::org.eclipse.jst.jee.server:web_moyoyo_ngtrade_backend::jst.web::2.5"/>  
10.   </server>  
11.   <server auto-publish-setting="2" auto-publish-time="1" configuration-id="/Servers/Tomcat v6.0 Server at localhost (4)-config" deployDir="wtpwebapps" hostname="localhost" id="Tomcat v6.0 Server at localhost (4)" name="wap_trade2015_8080" runtime-id="Apache Tomcat v6.0" server-type="org.eclipse.jst.server.tomcat.60" server-type-id="org.eclipse.jst.server.tomcat.60" start-timeout="45" stop-timeout="15" testEnvironment="true" timestamp="4">  
12.     <list key="modules" value0="wap_moyoyo_trade_2015::org.eclipse.jst.j2ee.server:wap_moyoyo_trade_2015::jst.web::2.4"/>  
13.   </server>  
14.   <server auto-publish-setting="2" auto-publish-time="1" configuration-id="/Servers/Tomcat v6.0 Server at localhost (5)-config" deployDir="wtpwebapps" hostname="localhost" id="Tomcat v6.0 Server at localhost (5)" name="wap_trade_8081" runtime-id="Apache Tomcat v6.0" server-type="org.eclipse.jst.server.tomcat.60" server-type-id="org.eclipse.jst.server.tomcat.60" start-timeout="45" stop-timeout="15" testEnvironment="true" timestamp="6">  
15.     <list key="modules" value0="wap_moyoyo_trade::org.eclipse.jst.j2ee.server:wap_moyoyo_trade::jst.web::2.4"/>  
16.   </server>  
17.   <server auto-publish-setting="2" auto-publish-time="1" configuration-id="/Servers/web_trade-config" deployDir="wtpwebapps" hostname="localhost" id="web_trade" name="web_trade" runtime-id="Apache Tomcat v6.0" server-type="org.eclipse.jst.server.tomcat.60" server-type-id="org.eclipse.jst.server.tomcat.60" start-timeout="45" stop-timeout="15" testEnvironment="true" timestamp="4">  
18.     <list key="modules" value0="web_moyoyo_trade::org.eclipse.jst.j2ee.server:web_moyoyo_trade::jst.web::2.4"/>  
19.   </server>  
20. </servers>  

其中有这么一行代码start-timeout="45" stop-timeout="15"。

即，不止定义了每个服务器的开始时间限制，还定义了每个服务器的停止时间限制。

这里，我们进入我们关注的第六个服务器tmp6。

进入tmp6文件夹，其中有个wtpwebapps文件夹。进入该文件夹可以发现有部署在该服务器下的项目的同名文件夹。

我们知道一个服务器上可以部署多个web项目。所以我们要找一个项目运行的所有文件，需要进入项目名文件夹中去找。

按常理来说，某个项目在Tomcat上部署运行所需要的所有东西，应当是全部在tmp文件夹中的-->wtpwebapps文件夹中的--->项目同名文件夹中才对。

那么关键的东西就都在项目名的同名文件夹下了。

这个项目文件夹里有什么东西呢？

为了防止遗忘，先回顾前面我们在Eclipse的项目名文件夹下的目录结构。

项目最原始的代码结构。java中

编译后产生的target文件夹中的代码结构

其中最核心的是classes文件夹和项目名同名文件夹。

而Tomcat部署目录下的项目同名文件夹的结构如下：

把资源文件下的文件夹放到根目录下，我们回过头去看Eclipse下的原始代码结构中src下的java、resources、webapp三个文件夹下的，webapp文件夹的结构。如下：

竟然是一模一样的。这就意味着有些东西，放到了这些文件夹中的某一个。应该。。。是WEB-INF文件夹吧。

进去之后果然，多了个classes的文件。

这里提一点。原本的Eclipse工作目录下的项目文件夹下。lib文件夹是在target文件夹下的，而src文件夹下并没有。src下的WEB-INF文件夹下只有那四个xml文件。

lib都放在target中。也就是，我们以后如果提交maven项目的核心原始代码。只需要提交src文件夹，其中就是不包含lib的。但包含了所有必要的其他东西。

而最原始的bbs项目，我们提交的时候都需要专门去删除lib文件夹。

这里可以看到一点点maven项目在项目结构上的优势了。虽然这些是题外话，也需格外注意一下。

说回来，上图中，这里的lib文件夹下是一堆jar包。

这里的classes文件夹下自然就是.class的字节码文件了。classes的文件夹结构如下：

其中，com下就是所有的java转过来的字节码文件了。其他的东西就是一些配置文件，我们可以看到其中有数据库的连接配置文件还有sql-map-config文件。

至此，所有预想过的运行需要的东西我们都在Tomcat的部署目录下找到了。

具备了java代码的字节码文件、包含了资源文件图片、js之类、还有jsp文件，具备解析jsp的能力。还有能够提供别人访问该项目的接口的能力，Tomcat的确可以保证这个网站可以运行起来，并被访问到。

 

至此，我们就理清了一个大型web项目从代码到可运行的过程，是怎么样的。

【如何实现从诞生到运行】

接下来，我们来探究这个过程的实现需要如何，需要如何，才能保证源码可以编译，编译后可以成功部署到服务器上。

这个过程，是src到target，是target到tomcat。

src到target，肯定是Eclipse帮我们做的。target到tomcat呢？应该是Eclipse和tomcat一起帮我们做的吧。

对，但Eclipse和tomcat是怎么联系到一起的呢？

就是如何在Eclipse配置tomcat的问题咯！回顾这个过程，

Eclipse下window下的preferences选项，其中有个server选项，顾名思义就是服务器的相关配置。就是在这里配置tomcat服务器的。

选择runtime environment，add新的服务器，选择好版本Apache Tomcat v6.0，然后next，需要在Tomcat installation directory，即tomcat服务器的安装目录中配置我们最初安装tomcat时候的安装目录位置。

这样，tomcat安装的位置，就被配置到了Eclipse中去了，Eclipse以后跑web项目的时候就可以使用tomcat服务器了。

我们正常跑一个web工程是怎么个过程呢？直接右击项目，run on  server。就会直接跑起来。这个过程中做了什么事情，我们也分析过了。

项目本身的代码是没有问题的，跑不起来，就是这个默认的过程出了一些问题。把这个过程手动进行一遍。

接下来说，这个工程跑不起来 的问题，是如何解决的！

【解决】

解决过程中遇到了两个clean操作！

这里涉及到了一个单词build，build在程序员的词典里，应当不是建造的意思，应当是编译的意思，build project的意思就是编译工程。

第一个clean。

Eclipse的project菜单栏下的clean选项。这个clean的作用，Eclipse也告诉我们了：Clean will discard all build problems and built states.The projects will rebuilt from scratch.即，重新编译的意思。

我们在project下除了clean选项还能看到别的选项。open project、close project、build all、build project、build working set（这个是什么意思，建立文件夹？对，是将工程按类放起来的选项）、（这里插个刚刚发现的小功能，把Eclipse下package explorer下的工程分类展示，右上角有个下拉三角，其中有个Top Level Elements，选择projects就是工程一个个展示，选择working sets就是分类展示）、build automaticlly即自动编译、还有generate javadoc、还有Properties。

其中的自动编译选项我们是打了勾的，即，Eclipse会帮我们自动编译。

如果我们选择clean，执行clean操作，就会先删除原有的.class字节码文件，然后同时重新编译一遍。

即，删除字节码文件后，重新生成一遍字节码文件。但是maven clean又是在做什么？

查到的资料显示，是清除maven工程的target目录下的文件。

我们测试了一下，的确是清除了文件，但不是全部清除，包含了.class文件的class文件夹就没有变化。也就是说，.class的字节码文件的编译还是Eclipse来做的。

而其它文件的生成却是maven本身的一些操作。因为target目录下的项目同名文件夹，里面可是各种资源文件呢。

而target下的这些jsp等资源文件和src下的webapp资源文件，结构和内容，除了lib，是一模一样的。

那最终部署到tomcat服务器上的时候，资源文件是来自于src下的webapp呢？还是来自于target下maven生成的那些资源文件呢？不知道！

 

第二个clean。

是tomcat服务器右击选择的clean。这个clean操作做的又是什么事情呢？

除了clean选项的另一个publish选项做的又是什么事情呢？查到的解释如下：

publish:是将你的web程序发布到tomcat服务器上，这样通过浏览器就可以访问你的程序。

clean：是指原先编译到tomcat服务器上的程序，先清除掉，然后再重新编译。

我们之前直接运行tomcat，看来是默认帮我们发布了。。。很多都不需要管。

但是出错了，就需要clean了，重新编译。然后运行tomcat服务器就可以了。

 

4.【Server returned HTTP response code:504 for URL】

这是我们在工程跑起来以后，又遇到的一个bug问题。504错误表示未找到，猜测是由于网络问题，导致应该访问的东西访问不到而报错。

后来也没有解决，只是无视掉了。工程可以正常运行，就无所谓了。

 

到这里记录过程就告一段落了。花了近5个小时的时间写了这篇博客。

追溯了Java工程在Eclipse中运行的逻辑，了解了项目结构等等。是为了以后不再因为一些模糊不清的东西，原地转圈。

OVER！

 

【12.24日更新】

搞清楚了maven clean真正做了什么操作。的确是清除了target目录下所有有价值的文件。包括.class文件还有jsp、js、css和图片等等。

但最核心的还是清除了.class文件，虽然classes的文件夹还在，其中的内容已经没有了。

我们不需要执行maven install或者maven build等给maven工程打包的相关操作。

只需要重新project clean就可以了。因为这个操作才是真正重新编译生成字节码文件的操作。

生成的字节码文件默认会放到target文件夹中的classes文件夹中去。

经检验，这个target文件夹中的class字节码文件与tomcat的部署目录中的字节码文件是同步的。

清了target文件夹，部署目录中的字节码文件也就没有了，所以跑不起来。

同样，如果我们执行一次project clean，字节码文件重新生成，部署目录中的class文件也会回来，工程就可以跑起来了。

而部署目录中的非java代码和资源文件。。。放进去了就没事了。可以猜想，这里的这些文件不和target文件夹同步，而是来自于src文件夹

中的webapp文件夹。只要源码不动，这里也就没事。

不过。。。这个猜想也有可能是错误的。因为有可能是target文件夹中之前执行过maven install和maven build操作，使得target中有了资源文件和jsp等等。

才能够成功放到部署目录中也说不定。

但是最起码，我们知道了如何看tomcat部署目录。部署目录中需要具备什么东西才能够成功运行。

也知道了工程跑不起来的真正原因了！

 

【12.24 日补充】

【deployment assembly】

在项目的属性中有这么一项，deployment assembly

我们可以看到这个选项中定义了什么内容。

这个选项就是定义了一些路径，即，路径与路径的对应关系。

路径的内容，我们发现是项目运行所需要的所有东西。而且是需要的全部东西，包括了源码的所有class文件和资源文件还有项目运行需要依赖的所有包。

我们看到class文件被定义的路径去向是：WEB-INF/classes，这是tomcat部署目录的路径啊。

即，这个菜单定义的是，项目运行所需要的东西，从项目文件夹到tomcat部署目录放的时候的路径！！

即，项目运行时为什么可以把这些东西准确的放过去，是因为定义了路径。

【maven --update project】

我们之前也遇到过maven---update project的操作。这个选项又是在做什么呢？

其实选项中早就告诉我们了，所以！使用一个选项的时候，一定要知道是在干什么！

去读一下！看到英文去读一下！Eclipse都告诉我们了。

 

这个更新工程的操作做的事情是：

更新根据pom文件对工程进行的配置，也就是jar包呗。也就是pom文件改了以后需要改这儿呗！

更新工作空间的资源，资源来源于本地文件系统，也就是源码呗。

clean 工程。这个不知道什么意思。

 

【pom文件】

pom文件定义了项目运行所依赖的很多包。运行项目的时候，通过这个链接到那些包。

我们在再次阅读这个文件的时候，发现不仅仅有基本依赖的包。

需要依赖的项目包的位置也早就已经写进去了！

在deployment assembly选项中，maven仓库中的包属于maven dependencies。

而项目依赖包也出现了。这些都是pom文件帮我们做的。