我有点震惊（如果？）这个确切的问题没有被问到，但是15分钟的扫描SO并没有完全匹配。 （如果我错了，请指出正确的方式并投票结束......）
在Ant构建系统下布置Java项目的最佳实践是什么？ 出于我们的目的，我们有以下背景（可能大多数是无关紧要的）：
project-root/ project-root/source project-root/source/java // main application (depends on -icd) project-root/source/java-icd // distributable interface code project-root/source/test // JUnit test sources project-root/etc // config/data stuff project-root/doc // pre-formatted docs (release notes, howtos, etc) project-root/lib // where SVN-managed or Ant-retrieved Jars go project-root/bin // scripts, etc...
在构建时，它扩展为包括：
build/classes // Compiled classes build/classes-icd build/classes-test build/javadoc build/javadoc-icd build/lib // Compiled JAR artifacts build/reports // PMD, FindBugs, JUnit, etc... output goes here build/dist // tarballs, zipfiles, doc.jar/src.jar type things, etc.. build/java // Autogenerated .java products build/build.properties // build and release numbering, etc...
如何在版本控制项和构建时工件之间的开发树中保持严格的分离 WHILE 生成一个连贯的分布 AND 允许我在开发和测试期间将开发树视为操作/分发？特别是，我不愿意将<jar>任务删除.jar文件放在顶级lib目录中 - 开发人员树中的目录是不可侵犯的SVN区域。但是，与build/lib/*.jar一起分发供公众使用的内容是令人困惑的烦恼。我们希望在分发中的一致位置出现的文档和其他构建工件也是如此，但不希望开发人员和用户使用完全不同的目录结构。
将所有生成的产品放在一个单独的build/目录中对于开发时非常好，但这是一个令人烦恼的工件。出于分配目的，我宁愿将所有JAR放在一个lib位置，事实上，像下面这样的结构最有意义。目前，我们使用ant dist动态构建此结构，通过执行一些复杂的路径操作，如.tar.gz和.zip工件构建。
project-root/ project-root/source // present in only some dists project-root/etc // same as in development tree project-root/doc // same as in development tree project-root/doc/javadoc // from build project-root/lib // all dependency and built JAR files project-root/bin // same as in development tree build.properties // build and release numbering, etc...
这个问题只是关于“我如何保持清洁的开发和分配项目布局？”正如我上面所说;同时也收集有关Java / Ant项目布局的信息，以及对我们特定方法的批评。 （是的，如果您认为它应该是社区Wiki，我会这样做......）
答案 0 :(得分：3)
布局方面，我们使用的东西已演变成非常接近Maven布局的东西（see here）。这是一个非常实用的布局，已被很多人使用。并且，如果您想稍后切换到Maven，那么您已经完成了设置。我们有几个变体，其中最重要的是我们将自动化单元和集成测试分开。
在混合来源和建造文物方面 - 我当然会建议反对它。正如您所见，它与IDE索引和版本控制相混淆，并且通常会使生活变得困难。
据我所知，要么必须接受这种混合，要么将依赖项作为构建的一部分进行复制，并将输出视为一个单独的项目 - 如果需要，可能会在另一个IDE窗口中不断打开。无论如何，将“作为用户”与“作为制作人”的工作混合在一起的想法听起来会让人感到困惑。
答案 1 :(得分：3)
我的一个建议是你分发的目录树不应该是CVS中的目录树。有一个脚本将build目录放在一起构建，然后将其拉上。该脚本可以将源控制文件和派生文件组合到其内容中。它还可以执行诸如清除SVN目录之类的操作，您不想分发这些目录。如果您希望能够以相同的方式处理开发和分布式树，只需确保dist的布局与开发项目的布局相同 - 最简单的方法是复制除build子目录之外的所有内容。 （和CVS目录，也许像Eclipse .project和.classpath这样的东西）。
我怀疑你不喜欢这个建议。您可能认为分布式文件只是开发环境的可移植版本 - 但我认为它不是，它永远不会是，并且它不需要。如果你能接受这个想法，你可能会觉得我的建议很合适。
编辑：我考虑了一下这个，并查看了我使用的一些脚本。我认为在这种情况下我要做的就是在开发过程中建立一个单独的树;将执行环境指向project-root / build / app（或者如果可以的话，可能是project-root / build）而不是project-root，然后是符号链接（或者如果没有符号链接则复制）所有必需品（无论是静态的） ，从项目根目录，或从构建中派生出来的那个。然后，构建分布可能就像压缩该树一样简单（当然，使用解析符号链接的工具）。关于这一点的好处是它允许执行树的结构非常干净 - 它不包含源目录，IDE文件，构建脚本或项目内部的其他支持文件等。如果您正在使用Subversion ，它仍然包含静态区域符号链接的任何内容中的.svn目录;如果您使用的是Mercurial，它将不包含任何.hg内容。答案 2 :(得分：1)
http://ant.apache.org/ant_in_anger.html
该项目包含子目录
答案 3 :(得分：0)
对于您可能想要查看的项目布局，还有一些（可能有点过时的）sun / oracle的一般建议：
Guidelines, Patterns, and Code for End-to-End Java Applications