首先说一下为什么要特别写一个文档来说明这个层次结构的事情，各位都在eclipse中使用java.io.File类读取过workspace中的文件，我相信在不了解eclipse目录层次结构的情况很少有人可以一次性把路径给写对了，为了避免以后再出现这种令人难堪的情况，还是编写这样一篇扫盲性的说明文档比较合适。当然重点绝不是上面的资源路径怎么编写，而是影响围绕整个工程的生命周期的构建活动。
首先看一下eclipse在默认情况下创建一个普通的Java Project的目录结构：
从上面可以看出来eclipse在创建一个Java Project的时候会创建一个默认的Source folder名为src，该文件夹下的所有文件经过编译之后会输出到同级的bin目录下。关于working set，很好理解，用来分类管理项目工程，你创建的工程主要用来做什么？属于什么类别？考虑完这两个问题你就知道放置在哪个具体的working set中了。
默认情况下，Package Explorer不显示working set，这需要将working set作为顶级元素的设定方法如下：
很多人在编写测试用例的时候喜欢用一个main方法在被测试程序内部中进行测试，如此把测试代码和生产代码混合在一起对程序可读性简直是毁灭性的打击，所以还是建立一个专门的测试类吧，测试类的命名最好遵从一定的规范这样大家都容易识别，建议将被测试类名+Test作为基本测试类的命名规则。关于测试类的存放又是有门道的，很多人喜欢在src下建立一个package叫做test，然后在这里面存放所有的测试用例。还是那句话，测试类不应该出现在生产环境下，所以还是将测试类放到一个单独的source folder下面吧。
下面分享一个创建测试用例的简便方法：
现在我有一个这样的类需要进行测试
package cn.seit.eclipse;
public class HelloEclipse {
public static String sayHello(String name) {
return "Hello" + name;
}
}首先在Package Explorer中选中HelloEclipse这个java文件，然后新建一个JUnit Test Case，eclipse会自动完成下面这些事情：
点击Next，选择需要测试的方法
完成之后，可以发现被测试类和测试用例的关系如下：
这样一来两者之间就建立了一定的对应关系，通过一方可以轻松知道另一方的存放位置。
引用上面将测试用例存放在一个专门的资源文件夹下的思想，我们同样可以将工程中产生的配置文件放置在一个专一的资源文件夹下。
Java Project发布一般是通过jar包的方式，我们可以在导出jar的时候做一下轻松设定，就将测试用例从生产环境中脱离了。
上面主要就是讲述了一个工程的资源文件的合理存放位置，用过maven的朋友对这种方式会非常熟悉，因为maven的工程结构就是这样子的。
Maven提倡使用一个共同的标准目录结构，使开发人员能在熟悉了一个Maven工程后，对其他的Maven工程也能清晰了解。这样做也省去了很多设置的麻烦。
以下的文档介绍是Maven希望的目录结构，并且也是目录创建工程是采用的目录结构。Maven推荐大家尽可能的遵守这样的目录结构。
| src/main/java |
Application/Library sources |
| src/main/resources |
Application/Library resources |
| src/main/filters |
Resource filter files |
| src/main/assembly |
Assembly descriptors |
| src/main/config |
Configuration files |
| src/main/webapps |
Web application sources |
| src/test/java |
Test sources |
| src/test/resources |
Test resources |
| src/test/filters |
Test resource filter files |
| src/site |
Site |
| LICENSE.txt |
Project's license |
| README.txt |
Project's readme |
看，maven的思想还是相当值得借鉴的，使用一个统一的标准目录层级结构可以为开发者大大降低沟通成本，提高团队的执行效率。我想在软件开发整个行业里面，大家遵循统一的标准对行业的发展会起到一个很好的促进作用，谢谢。
作者：萧易客
时间：2014/6/4