IntelliJ使用指南—— 深入理解IntelliJ的Web部署逻辑

这篇文章是先简单介绍一下这个过程,然后再谈一下如何简化这个过程的,最后说一个遇到的意想不到的问题。

首先摆出一个项目的目录结构图吧,由于IDE内部的结构树会隐藏一些中间临时目录,所以换成sublime来展示。

说明:从上到下,.idea和.settings分别是intelliJ和eclipse的相关依赖。build目录是class文件输出路径,这一点默认和eclipse是一样的。out目录是所谓artifact输出路径,即提供给tomcat的web程序目录,具体的web根目录就是下级的web_test_Web_explorded。接着下面就是src和WebContent两个开发目录也很常规。

那么,当你点击运行tomcat时,在默认设置下,就开始做以下事情

    • 编译, intelliJ在保存/自动保存后不会做编译,不像eclipse的保存即编译,因此在运行server前会做一次编译。图标是一个含有00 01 10字样的,非常形象。编译后class文件存放在build目录下。
    • 创建Artifact目录结构
    • 拷贝web根目录(WebContent)下的所有文件到out/artifacts/web_test_Web_explorded/下,即artifact目录下
    • 拷贝build下的classes目录到artifact下的WEB-INF下
    • 拷贝lib目录下所需的jar包到artifact下的WEB_INF下
    • 运行server,运行成功后,如有需要,会自动打开浏览器访问指定url

 

我们看到整个过程中,有着多次的拷贝行为,这个过程的目的就是为了让编译目录,资源目录和运行目录分开。同时,开发阶段的目录也无法让tomcat识别,比如classes放在了build目录下。所以若我们想要简化这个过程,就是需要减少拷贝的行为次数。

这个简化的结果并不会带来真正意义上的效率提高,因为IDE不会笨到每次拷贝都是全量拷贝。因此,今天我们的行为更像是一种加深web开发理解,熟悉IDE选项配置的过程。

目前tomcat所识别的web根目录为out/artifacts/web_test_Web_explorded/,如果我们能将这个指向换成我们的开发目录WebContent,就可以省下拷贝到artifact的过程;另外,WebContent下没有classes目录,所以我们要将编译输出路径改为WebContent/WEB-INF下,让输出的class文件直接放入WEB-INF下。

进入项目的设置窗口Project Structure(选中项目名按F4)

在Output path输入框中,原始值如下图高亮处。需要修改编译输出路径为:F:/work_spaceweb_test/WebContent/WEB-INF/classes

在Output directory输入框中(忘打高亮了),修改Artifact的输出路径为:F:/work_spaceweb_test/WebContent/

这样一来,我们就不需要额外的build目录和target目录了,这是我们最熟悉的eclipse思维。

下面讲一下一个一般情况下不需要去关注的目录。当tomcat运行起来后,在console会输出log信息,其中有一条是:

引用
Using CATALINA_BASE:   "C:\Users\Dev\.IntelliJIdea13\system\tomcat\Unnamed_web_test"

在这个目录下,放置了tomcat配置,如context.xml, server.xml等,这些配置都是intelliJ从tomcat安装目录的conf目录中拷贝过来的,每个项目会有一套。另外,还有catalina log, localhost log等。
这里有一个有趣的现象,Unnamed_web_test,这是这个目录的名字,很明显,Unnamed是默认加上去的prefix,但是我始终没有在idea的图形界面中找到这个设置name的地方,应该是这部分对使用者没有任何修改的意义,所以就不提供界面修改了。但是怀着研究的兴趣,我还是在idea的配置文件中找到了修改的办法。在项目下的.idea/workspace.xml文件中指定了命名,只要修改这里就OK了。但是必须用外部编辑器修改,在idea中修改会被还原。

引用
<server-settings>
<option name="BASE_DIRECTORY_NAME" value="Unnamed_web_test" />
</server-settings>

下一个环节,我要说一下我曾经遇到过的一个意外的事情。开始以为是IntelliJ的Bug,但是后来想通了,这是设计理念上和eclipse的不同造成。

项目中所使用到的jar包,大多数都是需要部署进server的,但有少数jar包只需要编译期或者测试期使用,无需部署进tomcat,甚至有的会与tomcat内置jar起冲突。而在一般的IDE或者maven中,jar包都是可以设置scope的,如provide,test, compile等等,前两者就是属于不需要部署进server的类型。

我的一个项目就遇到一个jar包编译期需要但是运行期绝对不能投进tomcat的情况。这本不是什么难事,如图,这里举例导入两个jar包,scope分别设置了provided和compile,(默认都是compile)。

然后到下图界面,看右侧available elements Panel的列表中出现了一个jar,即scope为compile的,然后右键它选择第一项,移入/WEB-INF/lib。而provided得jar则无法选择,这说明了,provided不会被部署进运行目录(artifact)。这就是前面IntelliJ逻辑步骤中灰色字体的含义。

但是!万万没想到,运行的时候,还是被加了进去!看了artifact目录下,还是出现了这个jar!这难道是IntelliJ的bug吗?百思不得其解。

后来一次机会发现问题的根源在哪里,答案就是:在IntelliJ的设计理念中,lib目录根本不是放在开发目录的WEB-INF下!请参考前面逻辑步骤中蓝色字体的句子,“拷贝根目录下所有文件......”,而我发现这个问题的原因是,是有一次通过IntelliJ创建web项目时,发现lib目录默认放在了src同级下…… 确实很意外

另外一个相关问题,之前一篇文章IntelliJ使用指南—— 导入Eclipse的Web项目中,谈到available elements部分时说:

引用
因为你会发现你即使不把jar包导入左边,运行时,lib下的所有jar包依然会拷贝到artifact目录下

现在应该清楚了,因为lib目录在WebContent下,因此会一起带过去。所以如果你的项目lib在这之下的话,avaiable elements这部分操作就无需做了,错误提醒也可以无视。

所以,以上就是IntelliJ IDEA在做web - tomcat开发的部署逻辑,以及IDE一些独有的特性。说实话,刚开始配的时候,觉得怎么这么难配,流程太复杂了,好像以前玩eclipse时候没怎么配就可以跑起来。但是现在清楚了配置和实现的关系以后,再回头看两者,就好像脱掉了衣服看到本质一样,其实是一模一样的,底下都需要符合jee的规范,上层么,只是一个界面而已。

发布者

Jiaheng Tao

挖掘概念,创造工具