IDEA跟Eclipse险些打一架。Maven:都住手,我来一统天下

共 6274字,需浏览 13分钟

 ·

2021-02-05 15:20

往期热门文章:

1、往期精选优秀博文都在这里了!
2、Typora + GitHub = 效率
3、女朋友为我写了一个防猝死插件
4、请谨慎使用Arrays.asList、ArrayList的subList
5全球顶级的14位程序员!膜拜!

前言

做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为例:

    Package Explorer视图

    所以请记住,这是和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、万亿级数据应该怎么迁移?
    3、从应用到底层 36张图带你进入Redis世界
    4、写代码有这16个好习惯,可以减少80%非业务的bug
    5、顺丰快递:请签收MySQL灵魂十连

    6一个基于SpringBoot + MyBatis + Vue的代码生成器
    7Redis 分布式锁使用不当,超卖了100瓶飞天茅台!!!

    8、如何设计订单系统?这篇写得太好了!
    9如果MySQL磁盘满了,会发生什么?还真被我遇到了!
    10、阿里开源的27个项目,值得收藏!
    浏览 29
    点赞
    评论
    收藏
    分享

    手机扫一扫分享

    分享
    举报
    评论
    图片
    表情
    推荐
    点赞
    评论
    收藏
    分享

    手机扫一扫分享

    分享
    举报