我有大约 50 个版本控制项目，我正在标准化它们的结构和构建方式。
每个在其根文件夹中都有一个 build.xml。我们还有一个项目，其中有一个构建文件，该文件由其他项目导入以执行常见任务。这使得这些常见任务的维护变得更加容易。
每个项目的 SVN 存储库都遵循树干/标签/分支的 svn 标准根结构。我们的工作空间是通过从主干检出的方式在 RAD 中构建的。当 rad 然后构建项目结构时，文件系统上没有创建实际的主干目录。项目只是从 workspaceRoot/projectName 开始，没有主干。尽管有关项目从何处签出的信息在项目名称后面的括号中，但您知道您正在处理的存储库的哪个分支。
我们支持在 RAD 中创建 File->Export 样式的战争，也支持战争文件的显式 build.xml 创建。所有这一切都很顺利。
现在开始在 Jenkins 中每晚构建这些项目，并努力解决 RAD 环境和 Jenkins 环境之间的一些文件结构差异。
例如，如果我有一个正在处理的特定项目，比如 project1，我的工作区中的 build.xml 位置将是
workspaceRoot/project1/build.xml
常见的 build.xml 文件同样位于
workspaceRoot/commonProject/build.xml
因此 project1 将尝试导入该构建文件
<import file="${basedir}/../commonProject/build.xml"/>
然而，在 Jenkins 中，当我指定存储库位置并进行结帐时，它会转到
jenkinsRoot/workspace/jobName/project1/trunk/build.xml
同样常见的项目 build.xml 位于
jenkinsRoot/workspace/jobName/commonProject/trunk/build.xml
所以 project1 构建文件中导入通用构建文件的语法将不起作用。我还有其他类似的问题，都与文件结构的差异有关。
看来这一定是一个相当普遍的问题，是否有解决此类问题的“最佳实践”方法。到目前为止，我已经做了很多搜索，但没有运气。
例如，如果 Jenkins 能够以与 RAD 相同的方式检查后备箱，那就太好了，但似乎不能。这至少可以让我使用 ant 的“可用”标签来查找两个可能的主干位置，并酌情使用正确的位置。但是一个有后备箱，一个没有。Jenkins 在工作空间路径中包含 jobName，而显然 RAD 没有这样的概念……等等。想要一种干净的方式来组合构建过程，无论是从 Rad 还是 Jenkins 启动都可以无缝运行。
-吉姆