往期热门文章： 
    
 
   
  
    
    
  

     
       
       
     
 
      1、 
     
     
       
       
     
 
      2、 
     
     
       
       
     
 
       
     
     
       
       
     
 
      4 
     
     
       
       
     
 
      5 
     

前言

做Java开发这么久了，是否曾经疑问过：

1. 为何项目中的xxx.iml、.idea文件夹明明起到重要作用，却不能被提交到git仓库，否则工资容易受损呢？
2. 这个项目他是用Eclipse开发的，我现在要用IDEA继续，担心结构上出现问题？
3. 为什么一个Maven项目被导入进IDEA了能正常work，它的项目结构Project Structure是咋样的？

若你也有这些疑问，那么看到本文你就来对了。

IntelliJ IDEA和Eclipse作为当下最为流行的两大IDE，它们在界面、操作、项目管理上是有很大差异的。正所谓两派之争必有一斗，到底该以谁的项目结构为标准？谁又选择去妥协呢？No，二者的答案都是这个

本文提纲

版本约定

• IntelliJ IDEA：2020.3.2
• SpringToolSuite：4.9.0.RELEASE

正文

接下来本文就从项目层面开始，探究这些问题都是如何被解决的~

IntelliJ IDEA项目

Eclipse项目

因为Eclipse项目本系列文章并未提及过，所以这里简单的介绍下。

实话说，A哥自2015年入行就从没用过原生的eclipse，所以这里就以基于Eclipse的STS为例了哈，道理都一样。

Eclipse它有workspace操作空间的概念，所有Project项目都是放在操作空间里管理起来的。换句话讲，Eclipse的一个窗口打开的是一整个工作空间，里面有多少Project就加载进来多少个，因此它可以实现：一个窗口同时打开多个Project项目。

新建一个Project

以新建一个名为hello的java项目为例：File -> New -> Java Project...

习惯了IDEA的选手，看到这个eclipse的这个页面，是否想感叹一句：一个项目创建页面为毛整这么复杂？像JRE、working sets这种选项完全没必要在创建时让选嘛，页面太不精简了，干扰信息太多。

点击Next：

呃，同样的感觉，且不说是新手，即使是老手看到这个页面也“乱花渐欲迷人眼”吧，O(∩_∩)O哈哈~。eclipse的页面设计基本都有这个毛病：过于复杂，干扰选项太多。比如这里插一个class类的创建页面，你感受一下：

点击Finish，Project创建完成了。

Project项目设置

鼠标选中项目（和IDEA不一样，此处必须选中），右键选择Properties就可以对该项目进行配置：

配置项“多如牛毛”，令人望而生畏呀。这里就不一一介绍了，图形化的东西了解起来也容易。但是你是否发现，众多配置项中却不见Module字样，怎么肥四？

Eclipse没有Module概念

如果想在hello项目下创建一个hello-client项目怎么办？答曰：在逻辑层面eclipse做不到，只能在路径结构下体现，具体创建动作为：点击新建项目，然后自定义这个路径，把它放在hello下面。

点击Finish后，项目结构上看如下图所示：

上图是Project Explorer，但若你切换到Package Explorer的话截图如下：

从这里能看出，eclipse在逻辑上是不存在层级概念的，没有module只有Project。

即便你导入的是maven项目（maven有模块概念）也是这样子，这里以dubbo为例：

所以请记住，这是和IDEA在逻辑结构上非常大的不同：Eclipse里并不存在Module，并不存在Module，并不存在Module。

解释.classpath和.project

eclipse的每个项目，还有两个附加文件：.classpath文件和.project文件。这两个文件比较特殊，没有文件名，以.开头，是隐藏文件。

我们知道IDEA里有两个特殊的文件workspace.xml和${moduleName}.iml，同样的eclipse里也有，我们可粗略的称作它们为环境描述符和项目描述符。

.classpath文件

.classpath文件存储了项目编译时Java构建路径，这个路径用$CLASSPATH可引用到。hello项目的此文件内容如下：

简而言之，.classpath定义了这个项目在编译时所使用的$CLASSPATH类路径。

.project文件

.project提供了项目的完整描述，包括名称、描述、项目类型等等。

对几个标签稍稍解释下：

• name：项目名称，一般和文件夹名称同名，但它们是两码事
• comment：项目注释
• buildCommand：构建使用的命令。这里值是 org.eclipse.jdt.core.javabuilder，也就是说是eclipse帮你编译的，而非你自己手动输入java命令编译
• natures：项目类型，这里 org.eclipse.jdt.core.javanature表示一个java项目

简而言之，.project是项目描述符，有了这个文件，eclipse加载项目时就可以按照它显示啦。

解释.settings目录

eclipse项目.settings目录下的配置比较杂，各种后缀名的都可能见到，绝大多数是文本文件，格式为properties或xml。Properties类型文件多数以.prefs为后缀名，XML类型文件多数以.*、.xml为后缀名。

因为类型众多，这里介绍几个较为常见的代表一下：

• org.eclipse.core.resources.prefs：规定文件的编码。尽量不要让一个项目中出现多种编码哟

• org.eclipse.jdt.core.prefs：指定一些Java编译的特性，比如编译版本、警告级别等等

结构差异，IDEA跟Eclipse打一架？

了解了IDEA和Eclipse的项目结构后发现，它俩对项目的管理方式是完全不一样的：

1. 不同的逻辑结构
2. 不同的元数据文件
3. 元数据文件的内容、格式都不一样

就因为这些差异的存在，就出现了不兼容问题：IDEA项目Eclipse不认识，反过来同理。虽然IDEA做了导入Eclipse项目的功能，但兼容性并不完美，完全是为了“协助”Eclipse倒戈IDEA的“权宜之计”而已~

也许你会说这影响不大呀，毕竟一个团队内一般不会出现既使用IDEA，又使用Eclipse的情况。诚然，一般确实不会有此类情况发生，but，视野放大点再想想呢？比如，如果是个开源项目呢？它面向的是所有开发者一起协作，总不能限制人家的IDE吧。还是拿dubbo来举例：要把源码全部提交到github上去的话，应该用IDEA的元数据文件还是Eclipse的呢？对于项目本身来说，项目名称、结构、依赖管理等都在元数据文件里保存着哩~

很明显，用谁的都不合适，毕竟现在Java平台的IDE还三足鼎立呢（至少还有两足），“得罪”任何一方都是不行的。况且，对于程序本身来说，IDE并不属于它的一部分，所以即便IntelliJ IDEA已一统天下了也不应该依靠它的元数据文件去帮你管理依赖、管理项目。花无百日红，明天谁知道呢~

这样子炒来炒去不会有结论的，那怎么办，难道非得“动手”？

面对这种情况，需要做的就是标准化，让所有的IDE都支持识别同一种项目/目录结构，问题自然迎刃而解了。这个时候有“人”就扛起了大旗，承担了这种角色的，它就是Maven（发音为[ˈmevən]，而不是“马瘟”）。

不管是何种IDE，都能识别和加载maven项目，解析其pom.xml文件生成为IDEA自己的元数据文件即可正常完成加载啦。因此，对于开发者来说，只需要面向Maven管理项目即可，再也无需关心具体IDE，这种差异性交由它帮你摆平。继续拿dubbo举例，在实操中它确实也是这么干的：只往github里提交了maven结构的源码和pom.xml元数据文件：

从此即使你用Eclipse，我用IDEA，也能正常的相爱了。

值得注意的是：既然使用了maven的项目结构，那么提交到github时，一些IDE自己的元数据文件就不能再提交了喽。因此，一般都会在项目的.gitignore文件里添加上如下配置项：

# eclipse ignore
.settings/
.project
.classpath

# idea ignore
.idea/
*.ipr
*.iml
*.iws

创建/导入Maven项目

既然Maven项目已然成为标准，因此在实际情况中不管是新创建，还是接触到的99.99都是maven项目。IDEA和Eclipse都提供了对maven项目的“完美”支持。

IDEA和Maven项目

创建Maven项目：

左边类别中选择Maven就表示需要创建一个maven项目，点击Next（当然你也可以选择一个模版骨架，如果公司有统一骨架的话）：

点击Finish，打开一个新的IDEA窗口，大功告成：

继续创建两个子模块（hello-client和hello-service），同样也用Maven项目：

点击Finish，并在子模块里添加Spring Context依赖：

并让hello-service模块依赖hello-client模块：

所以现在即使在hello-service模块里也能正常使用spring-conext相关类喽：

什么原因？查看项目的结构Project Structure一探究竟：

hello-client模块里的依赖：spring-context

hello-service模块里的依赖：

这里有spring-context的依赖，所以就能够正常使用。

发现没有，在创建此项目时，开发者只需要关心Maven方式创建，模块依赖的时候也只需更改Maven的元数据文件pom.xml即可，IDEA我会自动“解析”好放在项目结构Project Structure里并保存在它自己的元数据文件中（如xxx.iml文件等），从而确保了正常运行和管理。

打开/导入Maven项目：

打开窗口，选中pom文件（或者顶层文件夹）即可搞定。

导入maven模块时稍微有点不一样，了解一下：

❝

注意：在IDEA里Project项目是不存在import导入这么一说的，因为它是个独立体，只能说是打开项目

❞

选中某个文件夹后，确定进入下一步：

如图，IDEA支持把多种类型的模块导入进来，不可谓不强大：

• Android Gradle：若是安卓项目，选此项
• Eclipse：若是Eclipse项目，选此项（请注意：有eclipse元数据文件的才叫eclipse项目，而并不是对方用Eclipse开发就一定是eclipse项目，毕竟还有可能是maven项目嘛）
• Gradle项目：若是Gradle项目，选此项。比如Spring Framework项目
• maven项目：99%情况下，我们选择的应该都是此项

点击Finish即可把该模块导入进来了。

值得一提：很多“老程序员”在一个IDEA窗口里看似显示了多个“项目”，其实就是把一个Project当作一个Module模块导入进来了，这样做是非常不建议的，不信打开你的Project Structure瞅一眼，简直乱如麻，就是灾难无法管理。本系列前面文章详细介绍了这么做不妥的原因，并给了最佳实践。

Eclipse和Maven项目

大同小异，略。

Maven一统天下

❝

说明：本文并非Maven专题，仅对其一统天下的现状简单聊几句

❞

Maven是一个项目管理工具：包含了一个项目对象模型 (POM：Project Object Model)，一组标准项目结构，一个项目生命周期(Project Lifecycle)，一个依赖管理系统(Dependency Management System)，和用来运行定义在生命周期阶段(phase)中插件(plugin)目标(goal)的逻辑。

Maven的每个功能都是杀手级别的存在，非常强大和好用，中大型项目必备。譬如其依赖管理系统，若没有它的话依赖一个Jar得先去官网down一个对应版本的下来，然后添加到IDE里，打包的时候一起打进去，可谓麻烦至极且容易出错。

也不知道Maven什么时候早已一统天下了，反正A哥知道早在2015年Spring Framework团队就宣布其官网 再也不提供 Jar包的下载；在github上几乎所有的流行的Java项目都用通过Maven来构建和管理的；对于年轻一点的程序员来说，如果一个项目不是Maven项目，大概率不知如何上手，因为上学的时候默认就是按照maven项目来讲的。

如今2021年了，Maven项目是绝对的王者，事实的标准。不客气的说“几乎所有”中大型Java项目都是Maven项目（Spring Boot默认就是Maven项目），这或许是它的最大贡献之一，让全世界的Java开发者们统一了“语言”。Maven的存在也极大的巩固了Java生态，降低管理、构建、依赖管理的门槛，使得一直能以保持活力。

说到Maven就不得不提一提Gradle。可能有同学会说Gradle会替代Maven成为下一代最流行的项目管理构建工具，不信你看Spring Framework都迁过去用Gradle构建了。诚然Gradle作为新一代产品有很多“过人之处”，但在可预见的将来，Java平台里Maven依旧是绝对的标准，无可撼动。毕竟Maven功能非常完善，关键是没有致命的缺点，换的动力并不大的。而且存量市场过于庞大，船大难掉头甚至不会掉头。就像当年的xhtml一直雄心勃勃想干掉html一样，最后，你懂的~

❝

Gradle在Android开发中是主流，因此对于这种“新新技术”采用Gradle是不错的选择

❞

总结

本文介绍了IDEA项目和Eclipse项目的差异，目的是彻底的弄明白二者在项目管理上的区别，不要再人云亦云。

从小了说，本文能帮你解释为毛项目中的xxx.iml，.project等文件都绝对不要提交到github仓库，否则会被罚工资；从大了说本文告诉了你是Maven帮你做到了屏蔽差异让项目标准化的，这是不用再关心具体IDEA的底层原因。

❝

说明：在Maven之前是Ant来管理和构建项目，做到统一化。但因Ant有点久远了，所以本文直接以大家更为熟悉的Maven做解答

❞

当然喽，本文并非Maven专题，所以对它的描述也只是一笔带过。Maven的作用远远不止如此哈。

      
        
        
      
 
       1、 
      

      
        
        
      
 
       2、 
      
      
        
        
      
 
        
      
      
        
        
      
 
        
      
      
        
        
      
 
        
      

      
        
        
      
 
       6 
        
      
      
        
        
      
 
       7 
        
      
     
       
       
     

      
        
        
      8
     
       
       
     
     
       
       
     

      
        
        
      9
     
       
       
     
     
       
       
     

      
        
        
      10、