如何最好地在 EAR 中存储 Subversion 版本信息？
当收到错误报告或它不起作用的消息时，我的姓名缩写问题之一始终是哪个版本？ 由于不同的构建处于测试、规划和部署的多个阶段，这通常是一个不小的问题。
在发布 Java JAR（ear、jar、rar、war）文件的情况下，我希望能够查看/查看 JAR 并切换到与已发布 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 信息 http://svnbook.red-bean.com/en/1.1/re13 .html
subclipse svn 任务： http://subclipse.tigris.org/svnant/svn.html
svn 客户端： http://svnkit.com/
When receiving a bug report or an it-doesnt-work message one of my initials questions is always what version? With a different builds being at many stages of testing, planning and deploying this is often a non-trivial question.
I the case of releasing Java JAR (ear, jar, rar, war) files I would like to be able to look in/at the JAR and switch to the same branch, version or tag that was the source of the released JAR.
How can I best adjust the ant build process so that the version information in the svn checkout remains in the created build?
I was thinking along the lines of:
- adding a VERSION file, but with what content?
- storing information in the META-INF file, but under what property with which content?
- copying sources into the result archive
- added svn:properties to all sources with keywords in places the compiler leaves them be
I ended up using the svnversion approach (the accepted anwser), because it scans the entire subtree as opposed to svn info which just looks at the current file / directory. For this I defined the SVN task in the ant file to make it more portable.
<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>
Not all builds result in webservices. The ear file before deployment must remain the same name because of updating in the application server. Making the file executable is still an option, but until then I just include a version information file.
<target name="version">
<svn><wcVersion path="${dir.source}"/></svn>
<echo file="${dir.build}/VERSION">${revision.range}</echo>
</target>
Refs:
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 task: http://subclipse.tigris.org/svnant/svn.html
svn client: http://svnkit.com/
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（9）
在 Ant 脚本中使用 svnversion 命令获取修订号：
然后在 EAR 中的某处使用 ${svnversion} 属性。 我们将其放在 EAR 文件名中，但您也可以将其放在 EAR 内的自述文件或版本文件中，或者在 EAR 的 META-INF/manifest.mf 中指定版本：
Use the svnversion command in your Ant script to get the revision number:
Then use the ${svnversion} property somewhere in your EAR. We put it in the EAR file name, but you could also put it in a readme or version file inside the EAR, or specify the version in the EAR's META-INF/manifest.mf:
您需要提供 Subversion 分支和存储库编号。 正如如何访问当前 Subversion 内部版本号？中所述，
svn info命令将为您提供此信息，然后您可以使用该信息构建 VERSION 文件或将其放入您要构建到 *AR 文件中的任何其他文件中。 如果您没有其他想法，可以考虑使用 XmlProperty Ant 任务 从您的输出中提取相关信息svninfo --xml命令
You'd want to provide the Subversion branch and repository number. As discussed in How to access the current Subversion build number?, the
svn infocommand will give you this information, which you can then use to build a VERSION file or place in any of the other files that you're building into your *AR files. If you've nothing else in mind, you could consider using the XmlProperty Ant task to extract the relevant information from the output of yoursvn info --xml command
查看 jreleaseinfo 项目。 包含一个 ANT 任务，可以生成一个 java 类，可以在运行时调用该类来显示项目的发布信息。
我喜欢它的简单性。
Check out the jreleaseinfo project. Contains a ANT task that can generate a java class that can be called at runtime to display the release info for your project.
I like its simplicity.
另请参阅此问题：Java 项目的构建和版本编号（ant、cvs、hudson）
它包含几个有用的代码片段。
See also this question: Build and Version Numbering for Java Projects (ant, cvs, hudson)
It includes several helpful code snippets.
从我的脑海里。 每个 jar 构建的标签？
From the top of my mind. A tag for each jar build?
我们构建的第一部分在包的根目录中创建一个 version.txt 文件，并转储用于从（在我们的例子中）CVS 中检查代码的标记...此外，我们构建过程的最后部分检查将完全构建的 EAR 返回到 CVS 中以供将来参考。
这样，如果我们遇到 Web 应用程序问题 - 只需要求记者点击 /app/version.txt - 从那里我们可以深入 CVS 中的特定构建历史记录以找到相关组件（处理不同版本）应用程序中的库）来定位错误。
不确定这对我们的支持人员有多大帮助 - 但这绝对是他们抱怨不在场的事情！
We have the first part of our build create a version.txt file in the root of the package and dump the tag used to check the code out from (in our case) CVS... Additionally, the final part of our build process checks the fully built EAR back into CVS for future reference.
That way, if we have an issue with a webapp - it's just a case of asking the reporter to hit /app/version.txt - from there we can drill down the particular build history in CVS to locate the relevant components (handles different versions of libraries in apps) to locate the error.
Not sure how much help this is to our support folk - but it's definitely something they complain about not being there!
进行自动构建，并在构建成功时（当然使用单元测试）在代码库上放置一个标签（带有日期戳）。
在交付过程中，仅向客户交付标记的版本。 这样您就可以进行控制，并且可以将标记名称放置在 readme.txt 中的某个位置，或者让 Ear 文件的文件名反映标记名称。
我个人又改回了CVS，这也是原因之一。 在 CVS 中，我可以有一个班级报告它的标签。 我的所有 jar 文件都包含一个“main”，使它们可以运行。 对于支持问题，我要求客户执行“java -jar somejar.jar”并将输出与问题一起发送给我。
这样我就可以确定他们正在使用的版本，我什至可以获得 java 版本、操作系统类型和版本等信息。 客户不必回答奇怪的问题。
这很简单但非常有效。
Do automatic builds, and place a tag (with a date stamp) on the codebase when the build is succesful (with unittest ofcourse).
In your delivery process, only deliver tagged builds to the customer. This way you are in control, and can place the tag name in a readme.txt somewhere, or have the filename of the ear file reflect the tagname.
I personally switched back to CVS, and this is one of the reasons. In CVS, I can have a class report it's tag. All my jar files contain a "main" which makes them runnable. With support questions, I ask the customer to do a "java -jar somejar.jar" and send the output to me alongside the question.
This way I'm sure of the build they-re using, and I can even have information like java version, OS type and version. Without the customer having to answer strange questions.
It's simple but very effective.
为什么不将内部版本号放入属性文件中...然后 java 可以轻松读取该文件并将其输出到帮助 | 关于对话框（小程序/应用程序）、网页页脚或您可能拥有的任何其他 GUI。
（请参阅每个 SOF 页面上的页脚......那里有 SVN 版本号。）
看起来比在 WAR/EAR/JAR 等轻松时间中查找更容易加载？
Why not put the build number into a properties file... this can then be easily read by the java and output to a Help | About dialog (applet/application), web-page footer or whatever other GUI you might have.
(See the footer on every SOF page.... has the SVN version number there.)
Seems a load easier than looking in the WAR/EAR/JAR etc easy time?
我将绝对存储库修订版本存储为完整版本号的一部分。 这使人们可以快速浏览一下给定的更改是否在给定的版本中。
我们还将版本号/构建日期/等存储在ear的清单文件中作为自定义属性，这些大多仅供参考。 我们还将其存储在 jar 中内置的属性文件中，以便应用程序可以读取它。
I store the absolute repository revision as a part of my full version number. This gives people a quick glance to see if a given change is in a given version or not.
We also store the version number / build date / etc in the manifest file of the ear as custom properties, these are mostly informational only. We also store it in a properties file that is built into our jar, so the application can read it.