Deploying Programs

I checked out Java in Easy Steps from the local public library. After scanning the table of contents, I jumped straight to the chapter on deploying programs. This is an area of weakness for me in Java development. There are two ways to distribute Java programs. You can do so as a desktop application, which will require the Java Runtime Environment to be installed. Or you can do so as a web page applet. The second option will require the browser to have a Java plugin.

When rolling out a Java program, like any other installation, you need to make sure the resources required by the program are installed. The main way to include all the files you need is with a jar. Jar is a utility included in the Java SDK. You can find the program in the Java bin directory. This program has a command line interface.

The output of the jar utility is an archive file. You can run the program contained in the archive using the Java interpreter. Here is an example to create a jar file:

jar cf dL1.jar dL1.class.

Once you have the archive, you can inspect its contents using the following command:

jar tf dL1.jar

You can extract the full contents of the jar file like this:

jar xf dL1.jar

Jar creates a META-INF directory. Within that directory is the MANIFEST.MF file, also created by jar. You need to manually add the entry point for the program on the bottom line of that file as so:

Main-class: dL1

To run the program contained in the jar, you can execute the following command:

java –jar dL1.jar

Build Tools

When I first joined our project, our build scripts were written in the Korn shell. Our Korn shell programmer quit after I joined the team. Thus began our build script Hell. The scripts worked fine when everything was as expected. However they would bomb at the slightest disturbance. We needed a full time guy to baby sit this fragile set of Korn shell scripts.

Eventually a bunch of Java programmers joined the team. They decided the Korn shell scripts had to go. Being Java guys, they turned to Ant to do the builds. The result was a bit more reliable.

The Java guys got bored after a while. They started looking for ways to improve the build scripts. Maven was cited as a cool build tool. There was talk about redoing the build scripts again. However the Java guys left the project before any progress was made on that front.

It might be a blessing that we never ported our builds to Maven. I just read a rant describing Maven as pure evil. The author recommends you code your own build tool from scratch. He advises you to use Rake or Ant if you want to utilize a package. However he abhors Maven.

Here are the reasons to avoid Maven. It has the worst configuration syntax. The documentation is bad or incomplete. Maven is not flexible. It also has a broken dependency management subsystem. Exercise extreme caution if somebody tries to port your build scripts to Maven.