8

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/

4

9 回答 9

5

Use the svnversion command in your Ant script to get the revision number:

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

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:

<!-- myapp-r1234.ear -->
<property name="ear" value="myapp-r${svnrevision}.ear" />
于 2008-10-05T12:52:18.377 回答
4

You'd want to provide the Subversion branch and repository number. As discussed in How to access the current Subversion build number?, the svn info command 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 your svn info --xml command

于 2008-10-05T11:55:29.943 回答
3

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.

于 2010-04-02T11:20:35.073 回答
2

See also this question: Build and Version Numbering for Java Projects (ant, cvs, hudson)

It includes several helpful code snippets.

于 2010-05-21T21:35:15.127 回答
1

From the top of my mind. A tag for each jar build?

于 2008-10-05T11:51:44.850 回答
1

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!

于 2008-10-05T11:55:26.603 回答
1

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.

于 2008-10-05T11:57:00.220 回答
1

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?

于 2008-10-05T11:59:14.850 回答
0

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.

于 2008-10-20T20:49:19.080 回答