Groupwise 7 on Ubuntu 8.04

While web applications in browsers are continuing to improve, they still can't quite compete with desktop applications. One of the examples of this is the Novell Groupwise client. Running 64bit Ubuntu poses a bit of a challenge, since Novell only offer prepackaged rpm bundles for 32bit Red Hat and Suse systems. Note, some of this stuff is inspired by Scott's blog entry earlier this year, however I could never get his howto to work for me.

Start by downloading the Groupwise client RPM onto a 32bit version of Ubuntu (I use a 32bit image in VirtualBox). I'm not sure from where I found mine, but it's out there if you search a little. You should end up having a file called something like novell-groupwise-gwclient-7.0.3-20080310.i386.rpm

To convert this into a debian package, you are going to need alien. Get this by typing:

sudo apt-get install alien

With alien, you can convert the RPM into DEB by typing:

sudo alien -c novell-groupwise-gwclient-7.0.3-20080310.i386.rpm

Now you're done with the 32bit stuff. Move your novell-groupwise-gwclient_7.0.3-20080310.deb to your target 64 bit box. Before installing the DEB, make sure you have the nessesary dependencies. On my system I needed lib std. C++ 5 (you might need others as well) so I had to do:

sudo apt-get install libstdc++5

Install the Groupwise client itself by issuing:

sudo aptitude install novell-groupwise-gwclient_7.0.3-20080310_i386.deb

You should now have Groupwise installed in the /opt/novell/groupwise folder and shortcuts created on your desktop and in the Ubuntu Internet application menu. Groupwise is actually written (mostly) in Java, which it bundles (in my case the Sun JRE 1.5.0_06-B05). This works fine except if you are using Compiz, but I am so I needed to replace the 32bit slightly old bundles JRE with a newer one. Download a .bin from SUN's site, be sure to only download a JRE (not a JDK) and a 32bit (i586, not a amd64) one. Once downloaded, you can extract it to a folder by running:

sh jre-6u10-rc2-bin-b32-linux-i586-12_sep_2008.bin

Finally, we need to replace the JRE Groupwise is bundled with, with this new one you just extracted into the folder /jre1.6.0_10. So delete the folder /opt/novell/groupwise/client/jre/:

sudo rm -R -f /opt/novell/groupwise/client/jre

Then copy the new JRE in folder jre1.6.0_10/ to /opt/novell/groupwise/client/jre/:

sudo cp jre1.6.0_10 /opt/novell/groupwise/client/jre -R

There you go. That should give you Groupwise 7.03 running on the latest Ubuntu 8.04.

Java 6 update 10 on Ubuntu 8.04

The official Ubuntu 8.04 repositories comes with a slightly outdated version of Java, namely 1.6.0 update 6. If you issue a java -version you can assert this is the case:


Unfortunately, if you are running Compiz, you are likely to then suffer the notorious gray rectangle syndrome as described in 6429775, 6434227 and 6632124 among others. The good news, the problem appears to be fixed in update 10.

Installing the latest JDK
Start by downloading the JDK for your architecture from SUN. Take the .bin file, extract it by running it as a shell script:

sh jdk-6u10-rc2-bin-b32-linux-amd64-12_sep_2008.bin

This will create a new folder called /jdk1.6.0_10. Rename this to java-6-sun-1.6.0.10 (just to remain consistent with how Debian/Ubuntu refers to JDK's) and move this folder to /usr/lib/jvm:

sudo mv jdk1.6.0_10 java-6-sun-1.6.0.10
sudo mv jdk1.6.0_10/ /usr/lib/jvm

Officially you are suppose to use the update-java-alternatives command when using a Debian distro, but frankly I find it easier to do this manually. We need to update the /usr/lib/jvm/.java-6-sun.jinfo, so type:

gksu gedit .java-6-sun.jinfo

This will open up a hidden configuration file. The first line likely shows:

name=java-6-sun-1.6.0.06
...

Simply change this to point to the new version:

name=java-6-sun-1.6.0.10
...

Also, update the java 6 symlink to point to the one we just installed:

sudo rm /usr/lib/jvm/java-6-sun
sudo ln -s /usr/lib/jvm/java-6-sun-1.6.0.10/ /usr/lib/jvm/java-6-sun

This should actually work for most applications, but to be sure I always like to add a few common environment variables. Do this by typing:

gksu gedit $HOME/.bashrc

Scroll down to the end of the file and add two new lines:

export JDK_HOME=/usr/lib/jvm/java-6-sun
export JAVA_HOME=$JDK_HOME

That should do it. Issuing a java -version command now yields the latest version:


Remember the above isn't necessarily the official sanctioned way to do it, but it worked for me. Good luck to you!

Update:
It has come to my attention that Ubuntu 8.04 updates to the JVM overrides/reverts the modifications above. Keep an eye on this, I noticed it when starting seeing Compiz grey-box frames again in NetBeans.

@SuppressWarnings completion

Why it was made
Although NetBeans is capable of suggesting and auto-inserting @SuppressWarnings, it doesn't actually provide code completion or documentation for these values. Indeed, as I've blogged about before, it is tricky to track down the exact enumeration and semantics of these magic values. This is due to the fact that they are entirely dependent on the compiler and IDE. This plugin adds support for the values currently supported by NetBeans 6.1, namely "cast", "deprecation", "divzero", "empty-statement", "empty", "fallthrough", "finally", "serial" and "unchecked". It also tries to explain how and when to use them.



How it was made
Creating plugins for NetBeans is relatively easy if you start by grabbing existing code and have invested in the RCP book. Especially blogs like Geertjan's and Sandip's are virtual goldmines. So for this one, I used the Geertjan's blog entry entitled Caret Aware Code Completion. I had some trouble hooking into the Java parser as the tutorial shows, whenever invoking completion, there would be a lag between obtaining the caret position and resolving the current element. I did not figure out why this is, other than for some reason, the mapping from caret position to the underlying AST went out of sync. So instead I ended up relying only on the build-in Java lexer, which did not exhibit the same lag. This means there were a little bit of manual parsing to do, to assert if indeed the context invites for @SuppressWarnings values. The following scenarios had to be accounted for:

    @SuppressWarnings(STRING_LITERAL
    @SuppressWarnings({STRING_LITERAL
    @SuppressWarnings({STRING_LITERAL, STRING_LITERAL
    @SuppressWarnings(value=STRING_LITERAL
    @SuppressWarnings(value={STRING_LITERAL, STRING_LITERAL

In other words, we have to consume the Java token stream in reverse, from any open of closed STRING_LITERAL, and pass the following finite-state machine:



This is implemented by a simple recursive descent parser, which looks like this. Should you care to use it for your own parsing of a DSL inside Java String tokens, you can download the complete source code here.


Where to get it
There might still be some bugs and perhaps I a missing something, but if you want to give it a spin, you can download the plugin from NetBeans plugin central.

The hardest thing was to gather information regarding the valid values, since it differs from compiler to compiler and the various IDE's. If you do happen to find a bug or something incorrect, please let me know so I can correct it.