我有大约50个版本控制项目，我正在标准化它们的结构和构建方式。
每个根文件夹中都有一个build.xml。我们还有一个项目，其中有一个构建文件，由其他项目导入以执行常见任务。这使得维护这些常见任务变得更加容易。
每个项目的SVN存储库都遵循svn标准的trunk / tags / branches根结构。我们的工作区通过从行李箱退房而建在RAD中。当rad然后构建项目结构时，在文件系统上没有创建实际的trunk目录。项目只是在workspaceRoot / projectName中开始，没有主干。虽然有关项目签出位置的信息位于项目名称后面的括号中，但您知道正在处理的存储库的哪个分支。
我们同时支持RAD中的File-＆gt;导出样式战争创建以及war文件的显式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构建文件中的语法将不起作用。 我还有其他类似的问题，都与文件结构的差异有关。
这似乎是一个相当普遍的问题，是否存在解决此类问题的“最佳实践”方法。到目前为止，我已经做了一些没有运气的搜索。
例如，如果詹金斯可以像RAD一样检查行李箱，那会很好，但它似乎不可能。这至少可以让我使用一个蚂蚁“可用”标签来寻找两个可能的中继位置，并在适当的时候使用正确的中继位置。但是一个有一个主干，一个没有。 Jenkins在工作空间路径中包含jobName，而显然RAD没有这样的概念......等等。无论是从Rad还是Jenkins发布的，都希望能够以无缝方式组建构建过程。
-Jim