Eclipse Java 项目文件夹组织

Eclipse Java project folder organization

提问by Buggieboy

I am coming to Java and Eclipse from a C#/Visual Studio background. In the latter, I would normally organize a solution like so:

我是从 C#/Visual Studio 背景来到 Java 和 Eclipse 的。在后者中，我通常会组织这样的解决方案：

\MyProjects\MyApp\MyAppsUtilities\LowerLevelStuff

\MyProjects\MyApp\MyAppsUtilities\LowerLevelStuff

where MyApp would contain a project to build a .exe, MyAppsUtilities would make an assembly DLL called by the .exe, and LowerLevelStuff would probably build an assembly containing classes used by the higher-level utilities DLL.

其中 MyApp 将包含一个用于构建 .exe 的项目，MyAppsUtilities 将创建一个由 .exe 调用的程序集 DLL，而 LowerLevelStuff 可能会构建一个程序集，其中包含更高级别的实用程序 DLL 使用的类。

In Eclipse (Ganymede, but could be convinced to switch to Galileo) I have:

在 Eclipse（Ganymede，但可以说服切换到 Galileo）中，我有：

\MyProjects\workspace\MyApp

\MyProjects\workspace\MyApp

When I create my initial project. There is an option to put source and build files in same folder, but I have .java files created on a path that is reflective of my package hierarchy:

当我创建我的初始项目时。有一个选项可以将源文件和构建文件放在同一文件夹中，但我在反映我的包层次结构的路径上创建了 .java 文件：

\MyProjects\workspace\MyApp\src\com\mycompany\myapp\MyApp.java

\MyProjects\workspace\MyApp\src\com\mycompany\myapp\MyApp.java

My question is this: when I create subprojects (is that the right Java/Eclipse term?) for .jar files that will be analogous to the above MyAppsUtilities and LowerLevelStuff assembly DLLs in .NET, can (should) I organize the folders equivalently? E.g.:

我的问题是这样的：当我为 .jar 文件创建子项目（这是正确的 Java/Eclipse 术语吗？）时，这些文件将类似于 .NET 中的上述 MyAppsUtilities 和 LowerLevelStuff 程序集 DLL，我可以（应该）等效地组织文件夹吗？例如：

\MyProjects\workspace\MyApp\src\com\mycompany\myapp\myapputilities\MyAppsUtilities.java

\MyProjects\workspace\MyApp\src\com\mycompany\myapp\myapputilities\MyAppsUtilities.java

What is the standard/right way to organize this stuff, and how is it specifcally done in the IDE?

组织这些东西的标准/正确方法是什么，它是如何在 IDE 中具体完成的？

采纳答案by Adriaan Koster

Think of Java source code packages as one big hierarchical namespace. Commercial applications typically live under 'com.mycompany.myapp' (the website for this application might be 'http://myapp.mycompany.com' although this is obviously not always the case).

将 Java 源代码包视为一个大的分层命名空间。商业应用程序通常位于“ com.mycompany.myapp”下（此应用程序的网站可能是“ http://myapp.mycompany.com”，但显然并非总是如此）。

How you organize stuff under your myapp package is largely up to you. The distinction you make for C# between executable (.exe), DLL's and low-level classes does not exist in the same form in Java. All Java source code is compiled into .class files (the contents of which is called 'bytecode') which can be executed by a Java Virtual Machine (JVM) on many platforms. So there is no inherent distinction in high-level/low-level classes, unless you attribute such levels via your packaging. A common way of packaging is:

如何在 myapp 包下组织内容在很大程度上取决于您。您在 C# 中对可执行文件 (.exe)、DLL 和低级类所做的区分在 Java 中并不以相同的形式存在。所有 Java 源代码都编译成 .class 文件（其内容称为“字节码”），可以在许多平台上由 Java 虚拟机 (JVM) 执行。因此，高级/低级类没有内在的区别，除非您通过包装将这些级别归为此类。一种常见的包装方式是：

• com.mycompany.myapp: main class; MyApp (with a main method)
• com.mycompany.myapp.model: domain model classes; Customer, Order, etc.
• com.mycompany.myapp.ui: user interface (presentation or view) code
• com.mycompany.myapp.service: services within your application, i.e. 'business logic'
• com.mycompany.myapp.util: helper classes used in several places

• com.mycompany.myapp：主类；MyApp（带有一个 main 方法）
• com.mycompany.myapp.model：域模型类；客户、订单等
• com.mycompany.myapp.ui：用户界面（演示或视图）代码
• com.mycompany.myapp.service：应用程序中的服务，即“业务逻辑”
• com.mycompany.myapp.util：在几个地方使用的辅助类

this suggests a standalone Java app, it might be different if it is a webapp using one of the many frameworks.

这表明是一个独立的 Java 应用程序，如果它是使用众多框架之一的 web 应用程序，则可能会有所不同。

These packages correspond to a directory hierarchy in your project. When using Eclipse, the root of such a hierarchy is called a 'source directory'. A project can define multiple source directories, commonly a 'main' and a 'test' source directory.

这些包对应于项目中的目录层次结构。使用 Eclipse 时，这种层次结构的根称为“源目录”。一个项目可以定义多个源目录，通常是“main”和“test”源目录。

Example of files in your project:

项目中的文件示例：

src/test/java/com/acme/foo/BarTest.java
src/main/java/com/acme/foo/Bar.java
lib/utilities_1_0.jar

And inside utilities_1_0.jar:

在utilities_1_0.jar里面：

com/acme/foo/BarUtils.class

BarUtils.class this is a compiled java class, so in platform independent bytecode form that can be run on any JVM. Usually jarfiles only contain the compiled classes although you can sometimes download a version of the jar that also contains the source (.java) files. This is useful if you want to be able to read the original source code of a jar file you are using.

BarUtils.class 这是一个编译过的 java 类，所以以平台无关的字节码形式，可以在任何 JVM 上运行。通常 jarfiles 只包含已编译的类，尽管您有时可以下载包含源 (.java) 文件的 jar 版本。如果您希望能够读取正在使用的 jar 文件的原始源代码，这将非常有用。

In the example above Bar, BarTest and BarUtils are all in the same package com.acme.foo but physically reside in different locations on your harddisk.

在上面 Bar 的示例中，BarTest 和 BarUtils 都在同一个包 com.acme.foo 中，但实际上位于硬盘上的不同位置。

Classes that reside directly in a source directory are in the 'default package', it is usually not a good idea to keep classes there because it is not clear to which company and application the class belongs and you can get name conflicts if any jar file you add to your classpath contains a class with the same name in the default package.

直接驻留在源目录中的类位于“默认包”中，将类保留在那里通常不是一个好主意，因为不清楚该类属于哪个公司和应用程序，并且如果有任何 jar 文件，您可能会遇到名称冲突您添加到类路径中的默认包中包含一个同名的类。

Now if you deploy this application, it would normally be compiled into .class files and bundled in a .jar (which is basically a fancy name for a .zip file plus some manifest info). Making a .jar is not necessary to run the application, but handy when deploying/distributing your application. Using the manifest info you can make a .jar file 'executable', so that a user can easily run it, see [a].

现在，如果你部署这个应用程序，它通常会被编译成 .class 文件并捆绑在一个 .jar 中（这基本上是一个 .zip 文件加上一些清单信息的奇特名称）。制作 .jar 不是运行应用程序所必需的，但在部署/分发应用程序时很方便。使用清单信息，您可以使 .jar 文件“可执行”，以便用户可以轻松运行它，请参阅 [a]。

Usually you will also be using several libraries, i.e. existing .jar files you obtained from the Internet. Very common examples are log4j (a logging framework) or JDBC libraries for accessing a database etc. Also you might have your own sub-modules that are deployed in separate jarfiles (like 'utilities_1_0.jar' above). How things are split over jarfiles is a deployment/distribution matter, they still all share the universal namespace for Java source code. So in effect, you could unzip all the jarfiles and put the contents in one big directory structure if you wanted to (but you generally don't).

通常，您还将使用多个库，即您从 Internet 获得的现有 .jar 文件。非常常见的示例是 log4j（日志框架）或用于访问数据库等的 JDBC 库。此外，您可能有自己的子模块，这些子模块部署在单独的 jar 文件中（如上面的“utilities_1_0.jar”）。如何在 jarfile 上拆分是部署/分发问题，它们仍然共享 Java 源代码的通用命名空间。因此，实际上，如果您愿意，您可以解压缩所有 jarfile 并将内容放在一个大目录结构中（但您通常不这样做）。

When running a Java application which uses/consists of multiple libraries, you run into what is commonly referred to as 'Classpath hell'. One of the biggest drawbacks of Java as we know it. (note: help is supposedly on the way). To run a Java application on the command line (i.e. not from Eclipse) you have to specify every single .jar file location on the classpath. When you are using one of Java's many frameworks (Maven, Spring, OSGi, Gradle) there is usually some form of support to alleviate this pain. If you are building a web application you would generally just have to adhere to its layering/deployment conventions to be able to easily deploy the thing in the web container of your choice (Tomcat, Jetty, Glassfish).

在运行使用/包含多个库的 Java 应用程序时，您会遇到通常称为“类路径地狱”的情况。众所周知，Java 的最大缺点之一。（注意：帮助据说正在路上）。要在命令行上运行 Java 应用程序（即不是来自 Eclipse），您必须在类路径上指定每个 .jar 文件的位置。当您使用 Java 的众多框架之一（Maven、Spring、OSGi、Gradle）时，通常会有某种形式的支持来减轻这种痛苦。如果您正在构建一个 Web 应用程序，您通常只需要遵守它的分层/部署约定，以便能够在您选择的 Web 容器（Tomcat、Jetty、Glassfish）中轻松部署事物。

I hope this gives some general insight in how things work in Java!

我希望这能让您对 Java 中的工作方式有一些大致的了解！

[a] To make an executable jar of the MyApp application you need a JDK on your path. Then use the following command line in your compile (bin or target) directory:

[a] 要制作 MyApp 应用程序的可执行 jar，您的路径上需要有一个 JDK。然后在编译（bin 或目标）目录中使用以下命令行：

jar cvfe myapp.jar com.mycompany.myapp.MyApp com\mycompany\myapp

You can then execute it from the command line with:

然后，您可以从命令行执行它：

java -jar myapp.jar

or by double-clicking the jar file. Note you won't see the Java console in that case so this is only useful for applications that have their own GUI (like a Swing app) or that may run in the background (like a socket server).

或者双击jar文件。请注意，在这种情况下您不会看到 Java 控制台，因此这仅对具有自己的 GUI（如 Swing 应用程序）或可能在后台运行（如套接字服务器）的应用程序有用。

回答by matt b

Typically you would create related/sub projects as different Projects in Eclipse.

通常，您会在 Eclipse 中将相关/子项目创建为不同的项目。

回答by serg10

Maven has a well thought out standard directory layout. Even if you are not using it Maven directly, you can think of this as a defacto standard. Maven "multi module" projects are a fair analogy to the .net multiple assembly layout that you described.

Maven 有一个深思熟虑的标准目录布局。即使您不直接使用 Maven，您也可以将其视为事实上的标准。Maven“多模块”项目与您描述的 .net 多程序集布局非常相似。

回答by Thorbj?rn Ravn Andersen

There are two things you need to clarify before this question can be answered:

在回答这个问题之前，您需要澄清两件事：

1. Which source code repository will you use?
2. Which build system will you use to automatically build artifacts outside of Eclipse?

1. 您将使用哪个源代码存储库？
2. 您将使用哪个构建系统在 Eclipse 之外自动构建工件？

The answers will strongly influence your options.

答案将极大地影响您的选择。

We have opted for "one Eclipse project pr component" which may be either a library or a finished runnable/executable jar. This has made it easy to automate with Hudson. Our usage of CVS is also easier, since single projects do not have multiple responsibilities.

我们选择了“一个 Eclipse 项目 pr 组件”，它可以是一个库或一个完成的可运行/可执行 jar。这使得 Hudson 的自动化变得容易。我们对 CVS 的使用也更容易，因为单个项目没有多重责任。

Note, each project may contain several source folders separating e.g. test code from configuration from Java source. That is not as important as simplifying your structure.

请注意，每个项目可能包含多个源文件夹，例如将测试代码与 Java 源的配置分开。这并不像简化结构那么重要。