An echo-proxy build that actually works

In a previous post, I provided some software for downloading lectures from UWA's new Echo360 system.  Due to duplicate header problems, downloading lectures on Chrome was quite difficult; it was necessary to install a small proxy server (written in java) to get things going.


I've only just realised that the proxy server build I provided doesn't actually run; If you try to do so, you'll get a "class not found" error message.  Basically, I done goofed.

The problem is now fixed, and the build linked below should actually work.
http://dl.dropbox.com/u/1614464/echo_script/echo_proxy_0.1.1.jar

The source code, including the updated build script is here:
 http://dl.dropbox.com/u/1614464/echo_script/echo-proxy_source_0.1.1.tar.gz


Instructions for set-up and installation are unchanged; follow the procedure outlined in the previous post.

The error was due to the way java resolves dependencies within jar files (or perhaps more correctly, the error is due to me not reading all the documentation properly).

When you run a compiled java program "theprogram" from the command line, which has some dependencies in the file "dependencies.jar", you can get everything to work by setting the classpath.  ie

java -cp .:dependencies.jar theprogram

All well and good.  But now suppose that you want to package theprogram into a jar.  It is tempting to think that you could just set the classpath as before in the jar manifest
ie

echo "Main-Class: theprogram" > manifest.txt

echo "Class-Path: . dependencies.jar" >> manifest.txt

echo "" >> manifest.txt

jar cfm jarfile.jar manifest.txt theprogram.class dependencies.jar

Unfortunately, when you try to run jarfile.jar, you'll get an error.  Essentially, you can't have dependency jars within jars.  Which is really quite annoying. There are several ways to solve the problem; you can extract the contents of dependencies.jar, and then add the contents to jarfile.jar, for example.  Another method is to write a custom class loader as part of your program.  But neither of these are particularly good solutions: the first can lead to naming conflicts with complicated dependencies, while the second is unnecessarily complicated (particularly in a small project) and requires the program code to be modified before it is packaged.

Probably the best solution would be to actually fix the java runtime.  In fact, this particular nuisance is one of the top 25 RFEs for java; it has been for the last ten years.  Sadly, it seems Oracle doesn't really care.  While the problem is only a small nuisance, with several available workarounds, it surely wouldn't be too hard to fix.