基于Ant的构建的Java项目布局最佳实践

Question

我有点震惊(如果？)这个确切的问题没有被问到,但15分钟的扫描SO并没有完全匹配.(如果我错了,请指出正确的方法并投票结束...)

问题1:

在Ant构建系统下布置Java项目的最佳实践是什么？ 出于我们的目的,我们有以下背景(可能大多数是无关紧要的):

• 大多数开发人员都在使用Eclipse(并非所有)
• 项目维持颠覆
• 项目构建最近已迁移到Hudson,我们希望使用发布插件来管理版本,以及一些自定义脚本来处理自动部署
• 这个项目是一个"常规"应用程序,一种"生产原型",用户数量非常有限,但它们位于具有气隙分离的远程站点,因此可以提供版本化,可追溯的工件,以便于安装,手动数据收集/恢复,和远程诊断很重要.
• 一些依赖项(JAR)包含在SVN repo中; 如果需要,可以在构建时通过ant脚本获取其他内容.没有像Ivy那样花哨的东西(请不要告诉我切换到Maven3 ......我知道,如果/适当的时候到了,我们会这样做.)
• Build包括JUnit,FindBugs,CheckStyle,PMD,JavaDoc,一些自定义文档生成
• 两个或三个主JAR工件(一个主应用程序工件加上几个最小的API JAR,包含在几个耦合的应用程序中)
• 希望分发以下分发工件:
  • 一个"完整"源+ bin tarball,所有依赖项已解析,jars和JavaDoc预构建
  • 一个bin tarball,只有docs和JavaDoc,jar和辅助包装脚本等
  • 一个"合作伙伴"源+ bin,它具有合作伙伴开发人员可能关注的"共享"源以及相关的测试用例

目前的结构看起来像这样

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...

问题2:

我怎样才能保持版本控制项目和建设时工件之间在开发树严格分离WHILE产生连贯分布如上AND让我开发和测试过程中对待开发树作为业务/分配？ 特别是,我不愿让我的<jar>任务在顶级lib目录中删除.jar文件- 开发人员树中的该目录是不可侵犯的SVN区域.但是分发一些供公众使用的东西build/lib/*.jar是令人困惑的烦恼.我们希望在分发中的一致位置出现的文档和其他构建工件也是如此,但不希望开发人员和用户使用完全不同的目录结构.

将所有生成的产品放在一个单独的build/目录中对于开发时非常好,但这是一个令人烦恼的工件.出于分配目的,我宁愿将所有JAR放在一个lib位置,事实上,像下面这样的结构最有意义.目前,我们ant dist通过执行一些复杂的路径操作来动态构建此结构,如.tar.gz和.zip构建工件.

我认为dist应该是这样的:

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,我会这样做......)

Answer 1

我的一个建议是，您分发的目录树不应该是 CVS 中的目录树。有一个脚本，将 build 下的 dist 目录放在一起，然后将其压缩。该脚本可以将源代码控制的文件和派生文件与其核心内容结合起来。它还可以执行诸如清除您不想分发的 SVN 目录之类的操作。如果您希望能够以相同的方式处理开发树和分布式树，只需确保 dist 的布局与开发项目的布局相同 - 最简单的方法是复制除 build 子目录之外的所有内容（还有 CVS 目录，也许还有 Eclipse .project 和 .classpath 之类的东西）。

我怀疑你不会喜欢这个建议。您可能认为分布式文件只是您的开发环境的可移植版本 - 但我认为事实并非如此，永远不可能，也不需要如此。如果你能接受这个想法，你可能会觉得我的建议很不错。

编辑：我对此进行了更多思考，并查看了我使用的一些脚本。我认为在这种情况下我会做的是即使在开发中也构建一个单独的树；将执行环境指向project-root/build/app（或者可能是project-root/build，如果可以的话）而不是project-root，然后符号链接（或者如果没有符号链接则复制）所有必需的（无论是静态的） ，从项目根目录中，或从构建中派生）到其中。构建一个发行版可能就像压缩该树一样简单（当然，使用解析符号链接的工具）。这样做的好处是它允许执行树的结构非常干净 - 它不会包含源目录、IDE 文件、构建脚本或项目内部的其他支持文件等。如果您使用 Subversion ，它仍将包含从静态区域符号链接的任何内容内的 .svn 目录；如果您使用 Mercurial，它不会包含任何 .hg 内容。