SVN 修订号可在已编译的 GWT 包中访问
我有一个 GWT 项目,其源代码在 SVN 中管理,使用 Maven 打包,并通过 Hudson 管理其构建。我希望获得最新签入/构建的 SVN 修订号,以便在应用程序根 HTML 文件底部的注释中可见。我不在乎这种情况发生在开发过程的哪个阶段!
以下是我到目前为止在 Google 上搜索过的选项,但没有成功:
- 我可以让 Hudson 在构建后写下构建/修订号吗 到其构建输出文件之一(即应用程序根 HTML 文件)?我没见过有办法做到这一点。
- 我可以让 Maven 将 SVN 修订号写入其构建之一吗 输出文件(即应用程序根 HTML 文件)?我见过方法 Maven 将其写入 JAR/WAR 清单文件(然后可以 在 Java 代码中访问),但我不确定这是否适用于 GWT (我对 GWT 的内部结构不是特别了解)。
- 我可以让 SubVersion 作为预提交挂钩将版本号写入特定文件吗?我知道将版本号写入您正在编辑的文件很容易,但不太确定写入完全独立的文件(以便在每次提交时更新它,无论它在该提交中是否已更改)。
有谁有一个完整的、端到端的示例来说明如何使这些工作正常进行?我一直在寻找一些代码/配置的小片段,它们完成了部分工作,但并不是我正在寻找的任何东西。
谢谢!
I have a GWT project which has its source managed in SVN, is packaged using Maven and has its builds managed via Hudson. I want to get the SVN revision number of the latest check-in/build to be visible in a comment at the bottom of the application root HTML file. I don't care where in the development process this happens!
Here are the options I've Googled for so far, with no success:
- Can I get Hudson to, after building, write the build/revision number
to one of its build output files (namely the application root HTML
file)? I've seen no way to do this. - Can I get Maven to write the SVN revision number to one of its build
output files (namely the application root HTML file)? I've seen ways
of Maven writing this to a JAR/WAR manifest file (which can then be
accessed in the Java code), but I'm not sure that this works in GWT
(I'm not particularly knowledgeable about the internals of GWT). - Can I get SubVersion to, as a pre-commit hook, write the version number to a particular file? I know it's easy to write the version number to the file you're editing, but not so sure about writing to a totally separate file (so that it's updated on every commit, regardless of whether it was changed in that commit).
Does anyone have a complete, end-to-end example of how to get any of these working? I keep finding little snippets of code/config which do one part of the job, but not anything that is exactly what I'm looking for.
Thanks!
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
您可以通过 Maven 和 Hudson 的组合来实现您想要的目标。在此示例中,假设您希望 Web 应用程序根目录下的文件
version.txt
包含修订版本。version.txt
:在项目的
pom.xml
中,在maven-war-plugin
中启用过滤:确保 Hudson 正在通过以下方式构建您的项目: 。 Subversion checkout 会为每个构建设置 SVN_REVISION 环境变量,Maven 会填充它。
You can achieve what you're looking for with a combination of Maven and Hudson. In this example let's imagine you want the file
version.txt
at the root of your web app to contain the revision.version.txt
:In your project's
pom.xml
enable filtering in themaven-war-plugin
:Make sure that Hudson is building your project via. Subversion checkout and it will set the
SVN_REVISION
environment variable for every build and Maven will fill it in.此解决方案适合那些不断获取 {SVN_REVISION} 而不是目标文件中的实际 SVN_REVISION 值的用户。
我的解决方案是也使用过滤。然而,由于我希望 SVN_REVISION 出现在我的 gwt 应用程序的主 html 页面中(作为“对抗”用户缓存的一种手段,确保如果我们执行新的构建,那么用户会下载最新的 html 文件),所以我没有无法使用 Jason Terk 的解决方案。 html 文件只是打印了 {SVN_REVISION} 而不是实际的 SVN_REVISION 值。
所以我在
中定义了一个属性:然后我确保我正在过滤适当的 html 文件(如 Jason 的解决方案中所述),然后像这样“提取”html 文件中的 SVN_REVISION :
简而言之 - 我无法直接从 html 文件内部引用 {SVN_REVISION} 属性,因此我通过“包装”它
,让 maven 引用它。This solution is for those who keep getting {SVN_REVISION} instead of the actual SVN_REVISION value inside the target file.
My solution was to also use filtering. However since I wanted the SVN_REVISION to appear inside my gwt app's main html page (as a means of "fighting" the user's cache, making sure that if we carry out a new build, then the user downloads the latest html file), I wasn't able to use Jason Terk's solution. The html file simply printed {SVN_REVISION} instead of the actual SVN_REVISION value.
So I defined a property inside
<properties>
:I then made sure I was filtering the appropriate html file (like described in Jason's solution), and then "extracted" the SVN_REVISION in the html file like so:
In a nutshell - I wasn't able to directly reference the {SVN_REVISION} property from inside the html file, so I "wrapped" it through
<properties>
, letting maven reference it instead.