如何最好地将 Subversion 版本信息存储在 EAR 中？答案

【问题标题】：How best to store Subversion version information in EAR's?如何最好地将 Subversion 版本信息存储在 EAR 中？
【发布时间】：2010-09-15 08:52:11
【问题描述】：

当收到错误报告或无法正常工作的消息时，我的首字母缩写之一始终是什么版本？由于不同的构建处于测试、规划和部署的多个阶段，这通常是一个重要的问题。

在发布 Java JAR（ear、jar、rar、war）文件的情况下，我希望能够查看/查看 JAR 并切换到作为发布源的相同分支、版本或标记罐子。

如何最好地调整 ant 构建过程，以便 svn checkout 中的版本信息保留在创建的构建中？

我的想法是：

添加 VERSION 文件，但内容是什么？
将信息存储在 META-INF 文件中，但在哪个属性下具有哪些内容？
将源复制到结果存档中
在所有源代码中添加了 svn:properties，并在编译器保留它们的地方添加了关键字

我最终使用了 svnversion 方法（公认的 anwser），因为它扫描整个子树，而不是只查看当前文件/目录的 svn info。为此，我在 ant 文件中定义了 SVN 任务以使其更具可移植性。

<taskdef name="svn" classname="org.tigris.subversion.svnant.SvnTask">
  <classpath>
    <pathelement location="${dir.lib}/ant/svnant.jar"/>
    <pathelement location="${dir.lib}/ant/svnClientAdapter.jar"/>
    <pathelement location="${dir.lib}/ant/svnkit.jar"/>
    <pathelement location="${dir.lib}/ant/svnjavahl.jar"/>
  </classpath>        
</taskdef>

并非所有构建都会产生 Web 服务。部署前的ear文件必须保持相同的名称，因为在应用服务器中进行了更新。使文件可执行仍然是一种选择，但在那之前我只包含一个版本信息文件。

<target name="version">
  <svn><wcVersion path="${dir.source}"/></svn>
  <echo file="${dir.build}/VERSION">${revision.range}</echo>
</target>

参考：
svnrevision：http://svnbook.red-bean.com/en/1.1/re57.html
svn info http://svnbook.red-bean.com/en/1.1/re13.html
subclipse svn 任务：http://subclipse.tigris.org/svnant/svn.html
svn客户端：http://svnkit.com/

【问题讨论】：

我 SvnTask 比在接受的答案中运行“svnversion”更便携？

标签： java svn ant release

【解决方案1】：

您需要提供 Subversion 分支和存储库编号。正如How to access the current Subversion build number? 中所讨论的，svn info 命令将为您提供此信息，然后您可以使用这些信息来构建 VERSION 文件或放置在您正在构建到 *AR 文件中的任何其他文件中。如果您没有其他想法，可以考虑使用XmlProperty Ant task 从您的输出中提取相关信息 svn info --xml 命令

【讨论】：

【解决方案2】：

另请参阅此问题：Build and Version Numbering for Java Projects (ant, cvs, hudson)

它包括几个有用的代码sn-ps。

【讨论】：

【解决方案3】：

查看jreleaseinfo 项目。包含一个 ANT 任务，该任务可以生成一个 java 类，该类可以在运行时调用以显示项目的发布信息。

我喜欢它的简单。

【讨论】：

【解决方案4】：

我将绝对存储库修订存储为完整版本号的一部分。这让人们可以快速浏览一下给定的更改是否在给定的版本中。

我们还将版本号/构建日期/等作为自定义属性存储在 ear 的清单文件中，这些大多仅供参考。我们还将它存储在我们的 jar 中内置的属性文件中，以便应用程序可以读取它。

【讨论】：

【解决方案5】：

在您的 Ant 脚本中使用 svnversion 命令获取修订号：

<exec executable="svnversion" outputproperty="svnversion" failonerror="true">
  <env key="path" value="/usr/bin"/>
  <arg value="--no-newline" />
</exec>

然后在 EAR 中的某处使用 ${svnversion} 属性。我们将其放在 EAR 文件名中，但您也可以将其放在 EAR 内的自述文件或版本文件中，或者在 EAR 的 META-INF/manifest.mf 中指定版本：

<!-- myapp-r1234.ear -->
<property name="ear" value="myapp-r${svnrevision}.ear" />

【讨论】：

【解决方案6】：

为什么不将内部版本号放入属性文件中...然后可以很容易地被 java 读取并输出到帮助 |关于对话框（小程序/应用程序）、网页页脚或您可能拥有的任何其他 GUI。

（查看每个 SOF 页面的页脚......那里有 SVN 版本号。）

似乎比查看 WAR/EAR/JAR 等轻松时间更容易？

【讨论】：

【解决方案7】：

进行自动构建，并在构建成功时（当然使用 unittest）在代码库上放置一个标签（带有日期戳）。

在您的交付过程中，仅向客户交付带标签的构建。这样您就可以控制，并且可以将标签名称放在 readme.txt 的某个地方，或者让 ear 文件的文件名反映标签名称。

我个人切换回 CVS，这也是原因之一。在 CVS 中，我可以有一个班级报告它的标签。我所有的 jar 文件都包含一个“main”，这使得它们可以运行。对于支持问题，我要求客户执行“java -jar somejar.jar”并将输出与问题一起发送给我。

这样我可以确定他们正在使用的构建，我什至可以获得 java 版本、操作系统类型和版本等信息。客户无需回答奇怪的问题。

简单但非常有效。

【讨论】：

【解决方案8】：

我们构建的第一部分在包的根目录中创建一个 version.txt 文件，并转储用于从（在我们的例子中）CVS 中检查代码的标签......此外，我们的最后一部分构建过程将完全构建的 EAR 重新检查到 CVS 中以供将来参考。

这样，如果我们的 webapp 有问题 - 只是要求记者点击 /app/version.txt - 从那里我们可以深入 CVS 中的特定构建历史以找到相关组件（处理应用中不同版本的库）来定位错误。

不确定这对我们的支持人员有多大帮助 - 但他们肯定会抱怨不在那里！

【讨论】：

【解决方案9】：

从我的脑海里。每个 jar 构建的标签？

【讨论】：