在用 java 编写的软件项目中,您通常有资源,这些资源是项目的一部分,应该包含在类路径中。例如,一些模板或图像,应该可以通过类路径 (getResource) 访问。这些文件应包含在生成的 JAR 文件中。
很明显,这些资源应该添加到修订控制系统中。但是您将这些文件放在哪个目录中?与 java-source-files 并行还是在另一个也重现所需包结构的目录中?
Maven将它们放入 src/main/resources/ 中(Java 代码将转到 src/main/java/)。主要原因是 Maven 可以编译各种语言的代码,将它们分开是有意义的,这样一个编译就不会被另一个编译的文件混淆。
在资源的情况下,Maven 将在将它们添加到 Jar 之前替换其中的变量,因此它们也是“编译”源。
就个人而言,如果它们与代码的特定部分密切相关并且数量不多,我更愿意将它们与源代码放在一起。
但是,如果这些文件有自己的组织结构是有意义的,或者如果有数百个文件很难在其中找到源代码,我会将它们分开。
我更喜欢你的后一种解决方案:一个模仿源代码包结构的单独目录。这样它们就不会破坏您的源代码,而是紧挨着打包的 JAR 文件中已编译的类文件。
这取决于您的喜好。将它们与源代码文件混合在一起可以更轻松地进行重构,例如重命名包(因为资源与源一起移动),但是如果有多个图标、图像和本地化文件,您会很容易得到一堆杂乱无章的文件。
使用今天的工具,这也无关紧要。无论您使用 Eclipse、Netbeans 还是其他工具,它们都允许您拥有布局与源代码不同的二进制包。所以最后你可以随心所欲地做。
就我个人而言,我尽量避免将源代码与资源混为一谈,因为我通常很少更改资源,但会非常频繁地更改源代码。
我通常是这样的:
project/src
project/resources
project/classes
project/lib
project/dist
src和resources都具有包结构,构建文件将类和资源作为放置在dist中的 jar 的输入。
在内部运行时,类路径类似于:lib;classes;resources;
如果应用程序已安装,则安装程序会创建资源目录并将其原封不动地放置在安装中。
如果您的构建工具不会混淆,您可以将这些东西放在类路径中。Eclipse 不会尝试编译您的 jpeg,Ant 也不会,因此无需担心太多。好消息是,如果您有很多相关的东西,您可以将它们放在一起,按功能而不是按文件类型组织。
我们在我工作的地方这样做;我们有需要一些代码和少量静态资源的电子邮件。所有这些东西都保存在 java 源路径中的一个文件夹中;我们可以轻松地从系统中添加和删除电子邮件,而不会忘记某些事情或犯错误,例如 src/resource 路径不匹配或一棵树中的孤立文件不存在于另一棵树中。
如前所述,这取决于您,并且可能因项目而异。例如,使用Wicket.html
,将文件保存在类旁边是非常常见和实用的。另外,我经常将一些配置与源代码 - META-INF
, WEB-INF
, 日志记录在一起。
要让 Maven 从源代码树中获取资源,请使用以下命令:
<build>
<resources>
<resource>
<directory>src/main/resources</directory>
</resource>
<!-- Web - Wicket -->
<resource>
<filtering>false</filtering>
<directory>src/main/java</directory>
<includes><include>**</include></includes>
<excludes><exclude>**/*.java</exclude></excludes>
</resource>
</resources>
<testResources>
<testResource>
<directory>src/test/resources</directory>
</testResource>
<!-- Web - Wicket -->
<testResource>
<filtering>false</filtering>
<directory>src/main/java</directory>
<includes><include>**</include></includes>
<excludes><exclude>**/*.java</exclude></excludes>
</testResource>
</testResources>
保持资源分离的主要原因是(恕我直言)工作角色的分离。例如,如果您有一个包含翻译团队的项目,您将使用与代码分开的字符串和不同的 SCM 权限来保留资源。