Monthly Archives: February 2010

Every time I have to install a new Debian system I end up going to half a dozen pages to find all the steps needed to add Java to the system. I usually want to have both Suns JDK and OpenJDK install so that I can switch between them. So here is how to go about installing them.

To install Suns JDK the contrib and non-free repositories to apt. To do this edit /etc/apt/sources.list and add contib non-free to the end of both deb and deb-src ftp repositories. When done the lines should look something like this:

Now run apt-get update to refresh the package list.

Next we will install Suns JDK. Run the command:

Follow the instructions on screen.

Next we need to install Open JDK. Run the command:

Next we need to make sure that the correct JDK is chosen by default when running java. This is done using update-alternatives command. Run the command:

Select the version you want to run. It is useful to remember this command for when you want to change JVM implementation.

That's it. Java is set up and ready to be used.

2 Comments

After having automated our android project and getting everything to work, up and running on hudson and so on, we realised that the Android manifest xml file did not get automatically updated with the correct version numbers.

My initial idea was to use normal Maven properties, we do that in other parts of the project, to populate the values. However this does not work since the versionCode attribute must have an integer value for Eclipse to work. This ment that I would need to change the actual values in the manifest.

I had read a couple of blog posts about a Maven plugin called GMaven that have intrigued me. The plugin makes it possible to embed a Groovy script into a pom file and execute it during the build. Since Groovy makes changing XML easy this was the perfect fit.

Below is a script, embedded into the pom directives needed, that will automate setting version in the AndroidManifest.xml. It is triggered using the profile manifest-version-update. When triggered it will set the versionName attribute to the maven project version. It will also increment the versionCode attribute with 1 (versionCode++). The script should be placed in the Android application pom (I.E if you use a hierarchical structure this does not go in the parent pom).

I have yet to figure out how I can automatically trigger this when running the Maven release plugins prepare step. It would be perfect if it can be triggered once for the release pom and once for the snapshot pom during the release:prepare phase so that both the release tag and the trunk of the project has the correct version numbers. But that will have to wait a while.