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 dist for 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=0
Import 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" d开发者_如何学编程escription="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>

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:

project.version=<my_version_number>

In your build.xml file add the following snippet:

<property file="project-version.properties" />

Then you can append the version to your jar file like so:

<jar destfile="${dist}/prog-cli-${project.version}.jar">

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.

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

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:

Embed a build-id with your application.
Use said build-id to easily get the exact source code corresponding to the build-id.
Do bug fixes to said source code.

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.