Eclipse Engineering Standard Catalog hierarchy

First of all, why write a document specifically to illustrate the hierarchy of things, All of you have read the files in workspace using the Java.io.File class in eclipse, and I believe that few people can write the path at once without knowing the Eclipse directory hierarchy, to avoid this embarrassing situation in the future, or to write such a literacy document comparison Right. Of course the emphasis is not on how the resource path is written above, but on the building activities around the life cycle of the project.

First look at eclipse creating a directory structure for normal Java project by default:

As you can see from above, Eclipse creates a default source folder named Src when creating a Java project, and all files under that folder are compiled and exported to the bin directory of the sibling. About working set, well understood, used to classify and manage project projects, what is the project that you create primarily for? What category? With these two questions in mind, you know which specific working set to put in.

By default, the package Explorer does not display the working set, which requires that the working set be set as the top-level element as follows:

Many people like to write test cases with a main method in the test program inside the test, so the test code and Production code to mix together to the program readability is a devastating blow, so build a special test class, The name of the test class is best followed by a certain specification so that everyone is easy to identify, it is recommended to test the class name +test as the basic test class naming rules. The storage of the test class is also a doorway, many people like to build a package under SRC called Test, and then store all the test cases here. Still, the test class should not appear in the production environment, so put the test class under a separate source folder.

Here's an easy way to create a test case:

Now I have a class like this that needs to be tested

Package cn.seit.eclipse;

Public class Helloeclipse {

Public Static String SayHello (string name) {

return "Hello" + name;

}

}

First select Helloeclipse this Java file in the Package Explorer, and then create a new JUnit Test case,eclipse to do the following things automatically:

Click Next to select the method you want to test

When you are done, you can see the following relationship between the test class and the test case:

In this way there is a certain correspondence between the two, through which one can easily know the location of the other party.

Referring to the idea of storing test cases under a dedicated resource folder, we can also place the configuration files generated in the project under a single-minded resource folder.

Java Project publishing is typically done through a jar package, and we can detach the test case from the production environment by making an easy setting when exporting the jar.

The above is mainly about a project resource file reasonable storage location, using MAVEN friends to this way will be very familiar with, because MAVEN engineering structure is such a son.

MAVEN advocates the use of a common standard directory structure that enables developers to understand the other MAVEN projects once they are familiar with a MAVEN project. This also saves a lot of setup trouble.

The following document describes the directory structure that Maven expects, and is the directory structure in which the catalog creation project is based. MAVEN recommends that you adhere to this directory structure as much as possible.

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

Look, the idea of Maven is still quite worthy of reference, the use of a unified standard directory hierarchy can greatly reduce communication costs for developers and improve the efficiency of team execution. I think in the software development of the entire industry, we follow the unified standards for the development of the industry will play a very good role in promoting, thank you.

Genese

Date: 2014/6/4