使用 Ant 进行 Java 部署：帮助进行版本控制、测试等，以实现更好的构建
在过去的几个月里，我开发了一个 Java 项目，一个命令行实验分析工具。由于我没有计算机科学专业的背景（而是数学/工程），所以我很高兴能够通过战斗并学习项目管理和项目管理等概念。 POM、版本控制 (SVN) 和构建脚本 (ANT)。我之所以描述这一点，是为了描绘这样一个事实：与算法和公式不同，这些概念中的大多数对我来说并不是自然而然的（我想有人可以说我已经学会了成为一名“编码员” >”而不是“程序员”（如果这种区别有效/被接受）。
话虽这么说，我已经成功地使大部分工作正常进行，但有时相当不完整/丑陋。因为我想一路学习和提高，所以我想在这里提问。我今天使用的 ANT 文件是在一些帮助下创建的，附在下面。
鉴于这种情况，我想...：
问题 1： ...在某种程度上添加版本控制，以便当我将软件作为 jar 文件提供给全世界的用户时，他们和我可以有一种方法来跟踪潜在的问题和发展。附加到 JAR 文件名称的版本号（例如：prog-0.1.5.jar）以及运行时向用户提供的某种输出将是理想的选择。有人告诉我可以通过 ANT 实现这一点，但到目前为止我还没有运气。有什么提示或建议吗？
为此，我还收到了以下代码片段，但我不确定它在我的项目中为何/如何工作，因为我尚未声明这些属性/属性...
<svn>
<status path="."
lastChangedRevisionProperty="someproject.build" />
</svn>
编辑： 只是为了澄清我的一大堆问题，我想标准化我的项目中的版本控制。我可能以错误的方式使用这个术语，但现在完成版本控制的方式是：
- 我定期提交到 SVN 服务器以跟踪更改（并且还进行备份）
- 我手动尝试跟踪不同的版本 我
举一个我想在版本控制方面实现的目标的例子：
- 想避免手动版本编号；这很容易出错...
- 我想跟踪不同的构建，至少在本地使用它们的版本号，所以如果我碰巧需要调查旧的构建，我总是有旧的构建。 （我现在为新构建执行
ant dist-clean; ant dist，它只会覆盖旧的 JAR） - 如果版本号可以合并到构建中，那就更好了，所以一个信息行（例如“当 JAR 运行时，您现在正在运行 My_Awesome_software v:0.1.3")
- 要使用 SVN 作为版本跟踪、ANT 作为构建工具来完成上述操作。我不确定我是否有权更改服务器上的版本跟踪，而 Maven 在现阶段不是一个选择。中途学习似乎是一个问题，而不是它可能带来的任何好处...
问题 2： ...研究单元测试。我读过很多关于单元测试是现代编程的圣杯的内容，并且对几年前大学时的 JUnit 有一些遥远的记忆。我知道在理想的软件开发环境中单元测试绝对至关重要，但是我不知道在我的情况下应该/如何实现单元测试；其中该软件具有最小的用户界面（一个参数文件和运行时的几个可选标志）和与分析相关的较长（读取：小时）执行时间。
鉴于这种情况，不进行单元测试仍然被认为是一种不好的做法，如果是这种情况，在构建测试时我应该如何进行推理？
我觉得如果我尝试测试软件中的大部分功能，单元测试通常会比实际软件大几倍，并且执行时间甚至更长。
结论：我一直在使用 ANT 研究这个版本编号概念，我将很快为可能遇到相同问题的其他人总结我的发现：
创建一个属性文件，如 @Kevin Stembridge 提到的下面，例如 build.properties。我的看起来像这样：
micro.version=5
build.number=5
主要版本=0
secondary.version=0使用以下命令从此文件导入属性：
使用将所需的编号方案连接到 jar 标记中的 jar 名称。请参阅下面的代码。
单元测试是必要的，但是对于像我这样的项目来说很复杂。随着项目的发展我会研究它。
感谢每个以某种方式做出贡献的人，我选择凯文的答案作为接受，因为它是唯一对我的解决方案有直接影响的答案。
<target name="dist" depends="compile,static" description="Compiles and builds jar files">
<mkdir dir="${dist}"/>
<buildnumber file="project-version.properties"/>
<property name="version.number" value="${major.version}.${minor.version}.${micro.version}"/>
<svn>
<status path="."
lastChangedRevisionProperty="rev.number" />
<info target="." />
</svn>
<jar basedir="${build}"
destfile="${dist}/fever-${version.number}-rev${rev.number}.jar"
includes="**/*" />
</target>
I have during the past months developed a Java project, a command-line experimental analysis tool. As I don't have a CS-major in the background (Mathematics/Engineering instead) I have had the pleasure of battling through and learning concepts such as project management & POM, version control (SVN) and build scripts (ANT). The reason why I am describing this is to portray the fact that most of these concepts don't come naturally to me, unlike algorithms and formulas (I guess one could say that I have learned to be a "coder" not a "programmer" if such a distinction is valid/accepted).
That being said, I have managed to make things work for the most part, however rather incomplete/ugly at times. As I would like to learn and improve along the way, I thought of asking here on SO. The ANT file that I use today, created with some help over time, is attached below.
Given the situation, I'd like to...:
Question 1: ... add version control to some extent so when I supply the software as a jar file to users worldwide, both they and I can have a way of tracking potential problems and development. Version number attached to the name of the JAR file (for ex: prog-0.1.5.jar), along with some sort of output to the user at runtime would be ideal. I was told that this was possible via ANT but I have not had any luck so far. Any tips or suggestions?
I have also received the following code snippet for this purpose, but I am not sure why/how it would work in my project as I have not declared these attributes/properties...
<svn>
<status path="."
lastChangedRevisionProperty="someproject.build" />
</svn>
EDIT: Just to clarify my long chunks of questions, I would like to standardize the version controlling in my project. I might be using the term in a wrong way, but the way version control is done right now is:
- I do regular commits to an SVN server to track changes (and also to have backups)
- I manually try to keep track of the different versions of software
To give an example of what I want to accomplish regarding versioning:
- I would like to avoid manual version numbering; that's just so prone to errors...
- I would like to keep track of the different builds, at the very least locally, using their version numbers, so at all times I have older build if I happen to need to investigate an older build. (I now do
ant dist-clean; ant distfor new builds which just overwrite the old JARs) - It would be preferable if the version number could be incorporated into the build, so a informative line (e.g. "You are now running My_Awesome_software v:0.1.3") when the JARs are run
- To accomplish the above with SVN as version tracking, and ANT as a build tool. I am not sure if I have the liberty to change the version tracking on our server, and Maven is just not an option at this stage. It appears to be more of a problem to learn mid-stream than whatever benefits it might have...
Question 2: ... look into unit testing. I have read a lot about unit testing being the holy grail of modern programming, and I have some distant memories of JUnit from university a few years back. I understand that in an ideal software development environment unit testing is absolutely critical, however I have no idea how unit tests should/could be implemented in my case; where the software has minimal user interface (a parameter file, and a couple of optional flags at runtime) and a LONG (read: hours) execution time in connection with the analysis.
Given the situation is it still considered a bad practice to not have unit tests, if that's the case how should I go about reasoning when I structure my tests?
I feel like the unit tests would typically be a couple of times larger, and execute even longer than the actual software if I tried to test most of the functions in the software.
conclusions: I have been looking into this version numbering concept using ANT, I'll shortly summarize my findings for other who might run into the same question:
Create a property file as @Kevin Stembridge mentioned below, e.g. build.properties. Mine looks like this:
micro.version=5
build.number=5
major.version=0
minor.version=0Import properties from this file with:
<property file="project-version.properties"/>Concat the desired numbering scheme to the jar name in the jar tag. See the code below.
Unit testing is necessary, however complicated for a project like mine. I will look into it as the project develops.
Thanks to everyone who have contributed somehow, I am choosing Kevin's answer as accepted as it's the only one that had direct influence on my solution here.
<target name="dist" depends="compile,static" description="Compiles and builds jar files">
<mkdir dir="${dist}"/>
<buildnumber file="project-version.properties"/>
<property name="version.number" value="${major.version}.${minor.version}.${micro.version}"/>
<svn>
<status path="."
lastChangedRevisionProperty="rev.number" />
<info target="." />
</svn>
<jar basedir="${build}"
destfile="${dist}/fever-${version.number}-rev${rev.number}.jar"
includes="**/*" />
</target>
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
要回答问题 1：
要将版本号添加到 jar 和任何其他工件中，您应该创建一个名称如“project-version.properties”的属性文件。在其中添加以下行：
在您的 build.xml 文件中添加以下代码片段：
然后您可以将版本附加到您的 jar 文件中，如下所示：
回答问题 2：
这是一个大讨论，我不会详细介绍。为没有用户界面的代码创建一套好的单元测试当然是可能的（实际上更容易）。如果您知道给定输入期望收到什么输出，那么您可以编写一个测试来确认它。
回答问题 3：
您的构建文件看起来不错。我不认为它有任何问题。
关于使用Maven的建议。它将通过使用约定为您解决版本控制问题，但请注意，学习曲线并不是唯一的缺点。通过切换到 Maven，您将牺牲灵活性、简单性和可靠性。
To answer question 1:
To add a version number to your jar and any other artifacts, you should create a properties file with a name such as "project-version.properties". In it add the following line:
In your build.xml file add the following snippet:
Then you can append the version to your jar file like so:
To answer question 2:
Its a big discussion and I won't go into much detail. It is certainly possible (easier actually) to create a good suite of unit tests for code that has no user interface. If you know what output you expect to receive for a given input then you can write a test that confirms it.
To answer question 3:
Your build file looks fine. I don't see any problems with it.
Regarding the suggestion to use Maven. It will sort out your versioning issue for you by use of conventions but be aware that the learning curve is not the only downside. By switching to Maven you will be sacrificing flexibility, simplicity and reliablity.
我知道您专注于将 Ant 作为构建工具。不过，我鼓励您考虑 Maven。
您描述的一些问题就是 Maven 存在的原因。创建 JAR 文件之前进行单元测试的想法、构建版本号的想法、在源代码存储库（甚至 SVN）中分支和标记版本的想法都直接内置于 Maven 中。
缺点是它是另一种学习工具，而且学习曲线可能很陡峭。
I realize you are focused on Ant as a build tool. However, I would encourage you to consider Maven.
Some of the issues you describe are why Maven exists. The idea of unit testing before creating a JAR file, the idea of building in version numbers, the idea of branching and tagging a version within your source code repository (SVN even) are all built right into Maven.
The downside is that it is yet another tool to learn, and the learning curve can be steep.
1
一旦您拥有多个版本，您就需要版本控制！
如果你没有它，你最终会看到“啊，版本 4.5.1.2 源代码在那个 zip 文件中”，这很快就会变得非常乏味。
当您在版本控制系统之间进行选择时，请选择一个能够轻松实现以下功能的系统：
这在今天很常见。满足于此。我个人碰巧喜欢 git 和 github，但其他人喜欢 Mercurial 和 bzr。
2
不要忘记测试的原因。出现问题时需要尽快通知您！通常，这意味着您添加一个先前发生故障并已修复的场景，然后查看这次是否发生故障。您经常在构建服务器中执行此操作，每次检查版本系统时都会进行快速测试，并在工作时间之外进行长时间测试。
3
我不知道您是否应该更改 ant 文件中的内容，但我鼓励您使用一种方法，使 ant 构建文件和 IDE 配置可以保持一定程度的同步。我使用 ant4eclipse 使用 Eclipse 配置编写构建系统。这变得相当粗糙，我建议使用一个明确了解 ant 的 IDE。我认为这在 Eclipse 中效果不佳。
1
The minute you have more than one version, you need version control!
If you don't have it, you will end up in "ah, version 4.5.1.2 source is in THAT zip-file" and it very quickly gets very tedious.
When you choose between version control systems, pick one that easily allow you to:
This is commonly available today. Settle for no less. I personally happen to like git, and github, but others like mercurial and bzr.
2
Do not forget the reason for testing. You need to be told when things break, and as soon as possible! Frequently this means that you add a scenario that broke previously and was fixed, and then see if it breaks this time. You often do this in a build server which do the quick tests every time you check into your version system, and the long tests outside working hours.
3
I do not know if you should change stuff in your ant file, but I would encourage you to use an approach where the ant build file and the IDE configuration can be kept somewhat synchronized. I used ant4eclipse to write a build system using Eclipse configurations. This got quite gnarly and I would suggest using an IDE which explicitly knows about ant instead. I don't think this works well in Eclipse.