Eclipse 3.4 with openjdk 6 on OS X 32-bit CoreDuo

With the invaluable help of David Green, I was able to run Eclipse on openjdk 6 on my first gen MacBook Pro (you know, those left behind by Apple, running on a 32 bit CoreDuo processor… good to know that Apple supports the early adapters).

With this script that I adapted from David’s blog I was able to start Eclipse 3.4 (Version: 3.4.2
Build id: M20090211-1700) with Landon Fullers openjdk 6 build:

export JAVA_HOME=/Developer/Java/openjdk6-b16-24_apr_2009-r1
export PATH=$JAVA_HOME/bin:$PATH

java -server -Djava.library.path=$HOME/bin/jnilib -Dswt.library.path=$HOME/bin/jnilib -Xms128m -Xmx768m \
    -XX:MaxPermSize=192m -Dosgi.requiredJavaVersion=1.5 -Dorg.eclipse.swt.internal.carbon.smallFonts \
    -cp /Applications/eclipse/Eclipse.app/Contents/MacOS/../../../plugins/org.eclipse.equinox.launcher_1.0.101.R34x_v20081125.jar \
    org.eclipse.equinox.launcher.Main -os macosx -ws carbon -arch x86 -showsplash \
    -launcher /Applications/eclipse/Eclipse.app/Contents/MacOS/eclipse -name Eclipse \
    --launcher.library /Applications/eclipse/Eclipse.app/Contents/MacOS/../../../plugins/org.eclipse.equinox.launcher.carbon.macosx_1.0.101.R34x_v20080731 \
    -startup /Applications/eclipse/Eclipse.app/Contents/MacOS/../../../plugins/org.eclipse.equinox.launcher_1.0.101.R34x_v20081125.jar \
    -launcher /Applications/eclipse/Eclipse.app/Contents/MacOS/eclipse \
    -keyring $HOME.eclipse_keyring -consoleLog -showlocation -vm $JAVA_HOME

The script misses the shebang, since my hosting provider thinks that I’m trying to execute some serverside exploit…
You’ll have to extract a couple of shared libraries that are packaged in your Eclipse distribution:

jar xfv /Applications/eclipse/plugins/org.eclipse.swt.carbon.macosx_3.4.1.v3452b.jar
jar xfv /Applications/eclipse/plugins/org.eclipse.core.filesystem.macosx_*.jar os/macosx/liblocalfile_1_0_0.jnilib

You’ll have to rename all those libraries to give them a *.dylib extension.

Finally I had to point /System/Library/Frameworks/JavaVM.framework/Versions/1.6/Home to the openjdk 6 directory:

sudo mv /System/Library/Frameworks/JavaVM.framework/Versions/1.6/Home /System/Library/Frameworks/JavaVM.framework/Versions/1.6/Home.old
sudo ln -s LOCATION_OF_OPENJDK /System/Library/Frameworks/JavaVM.framework/Versions/1.6/Home

Maven-eclipse-plugin woes fixed

There is quite some anti-mavenism going around, about plugins suddenly not working, etc. And often this is true, case in point: maven-eclipse-plugin version 2.6 botched all projects working with Wicket by being very anal about what should live in the src/main/java directory tree (only Java files! God forbid you’d like to put web resources such as .properties (i18n for your web components), .js, .css, .html, etc next to your Java files. This version not only broke Wicket projects, but AspectJ as well.

Fortunately, the Maven community (more specifically Barrie Treloar and Arnaud Heritier) were helpful in finding the root cause of our pain: a conflict in merging the resources paths during the classpath generation.

With the latest snapshot of maven-eclipse-plugin 2.7 we now have our old build stability back, and can enjoy the new features of the maven-eclipse-plugin, such as searching your workspace for projects that are snapshot dependencies, and adding a project link instead of a jar dependency.

Yes, maven can sometimes be a pain, but ultimately with a great supporting and responsive community it will deliver. Many thanks to Barrie and Arnaud for being patient with us.

Downloading the internet with Maven in a new light

I have my share of complaints like everybody else about Apache Maven and one of them is that upon installation (or upgrading to a new plugin version) it starts downloading half of the available internet. Maven is constructed in a highly modular fashion, requiring lots of different, small, focused Java libraries. I’d like the distribution to contain those libraries, but I digress. Tonight I saw that not only Maven is structured this way. It is something *all* open source projects got.

For example, the much touted Ruby on Rails project with their disdain for everything Java would probably cringe at Maven (it uses XML after all). But installing Ruby on Rails and for example Radiant CMS with some plugins is a futile attempt in finding the right invocations of: script/*, rake, gem, port and other commandline tools you’ll want to get familiar with. All these tools start downloading stuff from the internet from different repositories (SVN, ruby forge, etc).

Maven: you’re not alone anymore in downloading the internet for your builds…

The sorry state of subversion support in Eclipse

Eclipse is a great IDE, but the state of subversion support is appalling. Both subclipse and subversive are buggy as hell, and I’d rather not touch either of them with a 10 feet pole.

Installing subversive is a futile exercise in “find all the update sites and correct plugin selection”. Subversive also is unable to keep the target/classes directory out of the synchronize view, which makes committing changes rather challenging.

Installing subclipse is much better than installing subversive: just add subclipse’s update site and install all plugins. No hunting for external sites, and no chance of installing the wrong stuff (I’m on OS X, so the win32 HL binaries are of no use to me). But again the team synchronize view is borked. This time subclipse won’t remove all updated files, double clicking on a folder throws an exception, etc.

I know that GIT is the SCM du jour, but please can someone at eclipse.org take note and finally implement a working, pleasant integration with subversion? Is that so much to ask after 5 years of Subversion availability?