Eclipse中⼀个Maven⼯程的⽬录结构（MacOS）
1. 为什么写这篇⽂章
在之前的javaSE开发中，没有很关注Eclipse⼯程⽬录下的环境，总是看见⼀个src就点进去新建⼀个包再写⼀个class。以后的⽇⼦中也没有机会注意到⼀个⼯程到底是怎么组织的这种问题，更不要说⾃⼰试试怎么控制了。
但是最近在学习Maven的时候知道了它对⼯程的⽬录结构有要求，也就是所谓的“惯例优于配置”。有⼀个被绝⼤多数⼈认可的java⼯程的⽬录结构被确定下来。这样统⼀了市⾯上各种复杂配置的⼯程。于是我便重新开始查资料，看看别⼈到底如何安排⼀个优秀的⼯程框架的。
同时，我也分析了Eclipse会给⼀个项⽬⽣成什么配置⽂件，其中的内容和意义⼜是什么.这样能⼼⾥⾯⼤致有个数，本地的什么⽂件是⼲什么的，怎么来的。
2. ⼀个简单的J2SE⼯程⽬录结构
⾸先，Mac中，⼀个默认的Eclipse⼯程的⽬录结构：
MyProject:⼯程的名字
src：⼀个源⽂件⽂件夹
com.jd.MyProject：⼀个包。⼀般是倒写的域名保证其独⼀⽆⼆性。
Main.java:⼀个java⽂件。
看上去就这么多？其实不是的，在我的mac环境下，⼀般时候Eclipse左边的⽬录是Package Explorer，也是是如上图显⽰的内容。但是其实可以⽤另外⼀个显⽰其真正的⽬录，也就是包含⼀些隐藏⽂件。叫Navigator(事实上Package Explorer默认隐藏Linux系统下的以.开头的隐藏⽂件，所以看不见，⽽Navigator默认打开)。显⽰效果如下：
3. 为什么Eclipse能认出来这些？
那么除了这些之外，其实还有值得探究的部分：
为什么Eclipse能识别出这个⼀个Maven⼯程？
Eclipse怎么识别Source Folder？
这些问题可以提出很多，其实本质上都是：Eclipse是⼀个集成开发环境，⽽Maven是⼀种项⽬管理及⾃动构建⼯具（维基百
科），Eclipse没有责任去“识别”Maven。这句话乍⼀听感觉和直觉不相符合：明明新建⼯程的时候选择新建⼀个Maven⼯程，Eclipse就知道这是⼀个Maven⼯程啊？明明导⼊⼀个Maven⼯程，Eclipse就能正确识别打开啊?
其实是Eclipse帮我们做了很多。所以问题的答案是：Eclipse是通过配置⽂件来“认知”⼀个⼯程的。⽽这些配置⽂件，都是⼀些隐藏⽂件。你新建⼀个Maven⼯程，其实是按照模板写好了这些配置⽂件，所以Eclipse才能读出来这个⼯程的相关信息。
（⼀）我们先看⼀个普通的J2SE⼯程的配置⽂件的内容和其效果，⼯程如下：
1，.settings⽂件夹下的那个⽂件：prefs。⾥⾯的内容是：
1 eclipse.preferences.version=1
degen.inlineJsrBytecode=enabled
degen.targetPlatform=1.8
degen.unusedLocal=preserve
pilerpliance=1.8
piler.debug.lineNumber=generate
piler.debug.localVariable=generate
piler.debug.sourceFile=generate
piler.problem.assertIdentifier=error
umIdentifier=error
piler.source=1.8
很明显，是明确jdk的，还有⼀些编译器的参数的配置。
2，.classpath。这个隐藏⽂件的内容是：
1 <?xml version="1.0" encoding="UTF-8"?>
2 <classpath>
3 <classpathentry kind="src" path="src" />
4 <classpathentry kind="con"
5 path="lipse.jdt.launching.JRE_lipse.jdt.internal.debug.ui.launcher.StandardVMType/JavaSE-1.8" />
6 <classpathentry kind="output" path="bin" />
7 </classpath>
这个⽐较重要，因为这个⽂件直接控制了⼀个⼯程的⽬录结构。kind属性为src，表⽰这个⽂件夹是放
源码的⽂件夹，物理位置在/src。也就是我们看到的那个⽂件夹。
kind属性为con，也就是config，⾥⾯控制的是这个⼯程的JVM，JDK，等等信息，⼀把来说我们不需要的修改。kind属性为output，说明了编译后产⽣的class⽂件放在物理地址：/bin⾥⾯。
看到这个⽂件的配置，我们就知道前⾯为什么⼯程的⽬录安排是那样的了，换句话说，正是这个⽂件的配置，⼯程才体现那样的⽬录。再进⼀步说，如果你在这个⽂件⾥⾯按照你的想法配置，那么你保存之后，项⽬的⽬录结构会⾃动变成你安排的那样。
3，.project。内容如下：
1 <?xml version="1.0" encoding="UTF-8"?>
2 <projectDescription>
3 <name>MyProject</name>
4 <comment></comment>
5 <projects>
6 </projects>
7 <buildSpec>
8 <buildCommand>
9 <name&javabuilder</name>
10 <arguments>
11 </arguments>
12 </buildCommand>
13 </buildSpec>
14 <natures>
15 <nature&javanature</nature>
16 </natures>
17 </projectDescription>
也是⼀些关于编译的配置⽂件，下⾯讲Maven还会讲到。
以上是⼀个普通java⼯程的所有⽂件和其⽬录结构，可以看到在我之前编写代码时没仔细注意的地⽅，⼀些配置⽂件对⼯程的结构做出了约束。
（⼆）接下来是⼀个Maven⼯程。
在Package Explorer⾥⾯看到的⽬录结构是：
⼏个不同点：
1. Source Folder不是⼀个简单的src，⽽是src/main/java
因为Maven是⼀种强约束的⼯程类型。它对⼯程的⽂件命名和格式要求⽐较严格。其好处是指定了规范，⽅便代码的移植和理解。上⽂中的src/main/java是个什么呢？其实是⼀个路径，打开其物理地址会发现，是⼀个src⽂件夹包含了⼀个main⽂件夹，再包含了java⽂件夹。这样的层次的⽂件路径⼀共有4个，如下：
src/main/java ：这个⽬录下储存主要的java代码
src/main/resources ：储存主要的资源⽂件。⽐如spring的xml配置⽂件和log4j的properties⽂件。
src/test/java ：储存测试⽤的类，⽐如JUNIT的测试⼀般就放在这个⽬录下⾯
src/test/resources ：储存测试⽤的资源⽂件
当然，这4个不是都必须有。前两个⼀般都有，后两个可能没有（不需要测试）。
与之类似的，如果⼀个包的名字是com.jd.MyProject，那么它在硬盘上的⽬录结构就是com/jd/MyProject。
2. 有⼀个target⽂件夹
很简单，就是源码编译后⽣成的class⽂件放的地⽅(如果是⼀个WEB应⽤，还有别的信息也在编译打包之后放在target⾥⾯)。具体放的时候也会根据是⼯程代码还是测试代码区分放置class⽂件。
3. ⼀个l。这个⽂件可以说是⼀个Maven⼯程最重要的⽂件了，因为这个是Maven的基础配置⽂件，和程序员打交道最多的也在这个⽂件⾥⾯，包括配置依赖关系等等。
根据上⽂描述，我们都知道了Eclispe⾥⾯的.开头的隐藏⽂件真正配置了⼯程的⽬录结构等等。那么这个Maven⼯程的配置⽂件⾥⾯写的是什么呢？
1，.settings：是Maven⼯程的⼀些配置，⽐如JDK版本和⽂件编码格式（UTF-8），⽐如⽗⼯程和⼦Module的依赖关系。
2，.classpath，这个⽂件内容变化了：
1<?xml version="1.0" encoding="UTF-8"?>
2<classpath>
3<classpathentry kind="src" output="target/classes" path="src/main/java">
4<attributes>
5<attribute name="optional" value="true"/>
6<attribute name="maven.pomderived" value="true"/>
7</attributes>
8</classpathentry>
9<classpathentry kind="src" output="target/test-classes"
10 path="src/test/java">
11<attributes>
12<attribute name="optional" value="true"/>
怎么把项目导入到eclipse13<attribute name="maven.pomderived" value="true"/>
14</attributes>
15</classpathentry>
16<classpathentry kind="con"
17 path="lipse.jdt.launching.JRE_lipse.jdt.internal.debug.ui.launcher.StandardVMType/J2SE-1.5">
18<attributes>
19<attribute name="maven.pomderived" value="true"/>
20</attributes>
21</classpathentry>
22<classpathentry kind="con"
23 path="lipse.m2e.MAVEN2_CLASSPATH_CONTAINER">
24<attributes>
25<attribute name="maven.pomderived" value="true"/>
26</attributes>
27</classpathentry>
28<classpathentry kind="output" path="target/classes"/>
29</classpath>
之前我们知道了⼀个Maven⼯程⽬录结构什么样⼦，这⾥就可以看出来为什么这个样⼦。正是这个⽂件的配置，让⼯程在Eclipse⾥⾯体现出来了与之前不⼀样的⽬录结构。具体⼀点就是它重新规定了各种⽂件（源码，配置，输出）在⼯程中存放的⽬录。事实上，你在Eclipse ⾥⾯做⼯程⽬录的修改的核⼼都是修改这⽂件，从⽽体现你的修改。
3，.l
这个⽂件可以说是很重要的，因为⼀开始我思考的问题是：怎么样把⼀个普通的JavaSE⼯程变成⼀个Maven⼯程的答案就在这⾥。我⼀点点修改，终于发现了最关键的⼀点，也就在这个⽂件⾥⾯。⽂件内容如下：
1<?xml version="1.0" encoding="UTF-8"?>
2<projectDescription>
3<name>MavenDemo</name>
4<comment></comment>
5<projects>
6</projects>
7<buildSpec>
8<buildCommand>
9<name&javabuilder</name>
10<arguments>
11</arguments>
12</buildCommand>
13<buildCommand>
14<name&aven2Builder</name>
15<arguments>
16</arguments>
17</buildCommand>
18</buildSpec>
19<natures>
20<nature&javanature</nature>
21<nature&aven2Nature</nature>
22</natures>
23</projectDescription>
可以看到多了两⾏。⼀个在buildCommand标签⾥⾯，⼀个在natures标签⾥⾯。如果你在⼀个普通的JavaSE⼯程⾥⾯加⼊了
<nature&aven2Nature</nature>
可以看到Eclipse就会在⼯程图标上加上⼀个M，认定其是⼀个Maven⼯程。删除这句话再保存，前⾯多出来的那句话也会⾃动删除。说明这句话正是确定这个⼯程“特性”的关键。
这个特性本⾝不重要，重要的是终于明⽩了，看上去很简单的东西，别⼈究竟是怎么实现的。在平常觉得理所当然的操作-->结果的背后，也许就体现了别⼈设计的智慧。⽐如这⾥：通过⽂件记录⼯程的⽬录结构。
以上就是Maven和普通⼯程的⼀些⼯程结构上的区别，以及造成这些区别的原因。
版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。
发表评论