Choosing Java Versions on Mac OS X

While debugging another manifestation of the "wrong library for groovy webtest" bug recently, I found an email thread that makes reference the java_home command (sadly, I can't find an online manual page to link to) to cleanly select a specific version of the JVM under OS X. Here I thought manually pawing through /System/Library/Frameworks to look for versions to set JAVA_HOME to was the "right" way to do it. Learn something new every day.

enjoy,
Charles.

WebTest Groovy example thows NoSuchMethodError

I've been working on a project to do functional testing on a web application using WebTest. I've coded up some prototypes using the standard XML/Ant format/language/DSL, but I wanted to try doing it in Groovy, since I'm not a big fan of XML. I copied the sample application from the manual, but when I ran it I was getting and exception:

Caught: : java.lang.NoSuchMethodError: org.apache.xpath.compiler.FunctionTable.installFunction(Ljava/lang/String;Ljava/lang/Class;)I
at test.run(test.groovy:33)
at test.main(test.groovy)

(If you're following along at home, you'll note that that line number is too large for the example - I've already hacked some stuff into it.)

I couldn't find any examples online of people having exactly the same problem, but I'd seen other errors blaming an old version of xalan.jar for this problem, especially under Mac OS 10.5 - my platform. (BTW, this happened under both Java5 and Java6.) Although I didn't have CLASSPATH set to anything, I figured I'd try setting it to have the version of xalan.jar that ships with WebTest, and it worked. So, my complete invocation line is:

groovy -cp /usr/local/java/webtest_1720/lib/xalan-2.7.0.jar -Dwebtest.home=/usr/local/java/webtest_1720 test.groovy

enjoy,
Charles.

Universal???

Apple has released Java6 for the Mac, which I have been eagerly awaiting. However, their download page is a bit contradictory:


This is limited to 64-bit Intel macs (which is fine with me), but yet they still call it Universal. What's Universal about that? The only way I could imagine it being less universal is if it they specified a number of cores or CPU speed.

Anyway, Java6 is good stuff for those of us on Universal Core2 Duo iMacs.


Charles.

What's in an OS X Package (.pkg) file?

I recently had occasion to figure out how packages work on OS X. This isn't an extensive treatise on the subject, and I didn't bother to look for any docs. This is just some poking around I did in the Finder and mostly in Terminal.

The original motivation was that I wanted to uninstall a package that I'd installed. The package file is Subversion-1.4.4.pkg. The first thing I learned is that packages are another case where a directory (aka folder) shows up as a single file in the Finder. You can see the contents in the Finder by control-clicking on the package file and selecting Show Package Contents. The Finder opens up a new window (just like any other folder).

All I see in my package is a folder called Contents. Within that folder, is a file called Archive.pax.gz, which is a compressed pax archive. Pax is an archive program like tar and cpio. (Actually, it's an experiment on genetic engineering - in order to "solve" the tar vs. cpio wars, they merged the two and called it pax, Latin for peace.) The pax archive was subsequently compressed with gzip - hence the gz extension.

Too see what's in the archive, we need to decompress it and get pax to print a listing of the contents. I did this as follows, although there are other ways to skin this cat:

cd /tmp
gzip -d < Subversion-1.4.4.pkg/Contents/Archive.pax.gz | pax -v

(Pax contains an option to do decompression, but I'm too old fashion.) Note that I redirect the compressed archive into gzip. I did this because I wanted to leave the archive compressed. I could have decompressed the archive and then ran pax on that, but I wanted to leave the entire package unharmed. The first bit of the output looks like:

-rwxr-xr-x 1 root wheel 1664424 Jun 22 23:57 ./usr/local/bin/svnadmin
-rwxr-xr-x 1 root wheel 1571744 Jun 22 23:57 ./usr/local/bin/svndumpfilter
-rwxr-xr-x 1 root wheel 1664612 Jun 22 23:57 ./usr/local/bin/svnlook

So, we can see that these are the files that got installed (in /usr/local). One nice thing to note is that the path names are all relative - they begin with "./" rather than just "/". This means the files can be installed anywhere - change into a directory, extract the archive, and the files will show up in a directory called usr/local below your current directory.

How can I use all of this to uninstall these files? Again, there are many ways to skin the cat, but here's what I did. I extracted the archive to /tmp. ("I thought you wanted to remove the files. Why are you extracting them again?" Patience, my friend.)

cd /tmp
gzip -d < Subversion-1.4.4.pkg/Contents/Archive.pax.gz | pax -r

This creates all of the files, but under /tmp - e.g., /tmp/usr/local/bin/svnadmin. I can now use find to get me a list of just the files:

find usr -type f -print > /tmp/fff

I then looked through the file names in /tmp/fff, and they made sense, so I removed them all.

sudo rm -i `cat /tmp/fff`

The sudo command was needed because the files were not owned by my user ID. The package installer asked for the administrator password and installed the files owned by root (as I recall). Of course, I could have avoiding "installing" the files in /tmp by running the output of pax -v through some awk or perl, but the archive was small, and I knew the options to find off the top of my head - I would have had to look up some awk or perl, since I don't use them that often any more.

enjoy,
Charles.

P.S. This post almost never was: Blogger mangled the fonts repeatedly, and I almost gave up on it. Stupid JavaScript HTML editors!