Why doesn’t Eclipse/Installation Manager work on Linux?

For the next time I’m grumbling about yet more incompatibilities causing problems with Eclipse on Linux, adding the following properties to the bottom of the launcher configuration file seems to help:


For example, edit the install.ini file for Installation Manager, which is where I first encountered problems after updating Red Hat Enterprise Linux last year. The problem appears to be due to incompatible GTK and Cairo versions, and there’s a related IBM technote for Installation Manager on RHEL 6.6.

Unfortunately, while that was enough to get Installation Manager working, the Eclipse IDE still seems somewhat unstable. I been exporting the following environment variable for a while but, based on the SDK Known Issues wiki page, maybe that doesn’t make any difference with recent versions:


Another suggestion I’ve seen recently, related to tooltips, is to export another environment variable, although so far I haven’t tried it:

export GRE_HOME=/dev/null

Need to experiment a bit more with those last two, and see if I can narrow down whether there are any other real problems.

MQTT Joggler

Spurred on by the success of getting Mosquitto working on a Raspberry Pi, I recently had a play with MQTT on the Joggler. The O2 Joggler is still a great device for hacking and I currently have SqeezePlay OS running on it.

The reason I wanted to try and get MQTT on the Joggler was to make use of its light sensor, and publish light levels over MQTT. It all turned out to be pretty simple since most of the work has already been done by other people!

First thing to do was read the light sensor and get that working with an MQTT client. I had to skip some of Andy’s instructions and just built the client code rather than attempting to get doxygen working. Once I’d mashed up the light sensor code and publish example I could compile the worlds most pointless MQTT publisher:

gcc -Wall publightsensor.c -L../bin/linux_ia32 -I../src -lmqttv3c -lpthread -o publightsensor

Next it was time to check the results. This too was quick and easy thanks to the MQTT sandbox server, which has a handy HTTP bridge. And the final result… was a completely unscientific and slightly dingy light level 4! Now I’ll be able to turn on a lamp using an unreliable RF controlled socket and see whether it worked or not!

Update: the code really is all in the existing examples but I’ve created a Github Gist in case it’s any help: mqttjogglermashup.c (11 February 2013)

Checkbox fail

Apologies if this is a repeat grumble, but every time I export an EAR file from RSA the dialog box annoys me. Well, that’s a bit unfair, it’s not the whole dialog box, just one very pointless checkbox on it…

So the first time I attempt to export to a destination which already exists, I get a helpful error preventing me doing something potentially stupid. When I know that I’m just re-exporting the same EAR and I’m happy to just overwrite the old one (which probably wasn’t working because I forgot to include something important) I just need to check the “Overwrite existing file” box to make the error go away and I can hit finish. Lovely… except that the dialog remembers this option next time I come to do an export! Basically it may as well not exist after the first export.

It’s actually a bit of a love hate relationship with this little checkbox though, because if it always defaulted to unchecked I think I’d much prefer it to having a dialog popping up asking whether I want to overwrite an existing file. Oh well, almost useful.

Anyway, it’s Friday and time to go home; check.

Generated… not

Using JMerge makes it easy to combine generated code with custom code, preserving any modifications when re-generating. So, for example, you might have this generated code:

  * some generated code which hasn't been modified
  * @generated

public void doSomething() {
   // anything here can get overwritten when the
   // code is regenerated

Which you might modify:

  * some generated code which has been modified
  * @generated NOT: added important bit

public void doSomething() {
   // really important stuff which I don't want overwritten
   // when the code is regenerated

Nice but, having a short memory, I need a way to keep track of all these modified bits of code and luckily the Java task tag feature in Eclipse comes to the rescue with a simple solution. Open ‘Window > Preferences…’ in the main Eclipse menu. Find the ‘Java > Compiler > Task Tags’ page. Press the ‘New…’ button and enter the following details:

  • Tag: “@generated NOT”
  • Priority: Low

Problem solved: the tasks view will list everything you changed!