I have been fooling around a bit with Eclipse, Subclipse and the Fink package
svn-javahl, trying to get Subclipse to work together with
svn-javahl. Thanks to a fix by the package maintainer, Daniel Johnson, there is now a really easy solution available.
Note 1: You need
svn-javahl-1.6.5-2 or later for the solutions in this article to work. If you use an earlier version of the package, Eclipse is likely to crash at some point. Read the article for more details.
Note 2: The original version of this article was posted on this website for less than 24 hours. It has been completely outdated by Daniel's fix, so what you are reading now is a totally revised version of the article.
Solution 1: Global and easy
Log in as an admin user, open a terminal window and type the following:
mkdir -p /Library/Java/Extensions # do this only if the folder does not exist cd /Library/Java/Extensions ln -s /sw/lib/svn15/libsvnjavahl-1.jnilib .
That's all, you are already done. From now on, every Java application on your machine will have access to JavaHL provided by the Fink package. This, of course, includes Eclipse. The nice thing is that you can install a new version of Eclipse, or have multiple installations of Eclipse, or update the Subclipse plugin, or even start to use a different SVN Team Provider (e.g. Subversive), and everything will still work.
The "Java Extensions" mechanism is documented in Apple's official Mac OS X Reference Library. It's also mentioned in this article on today.java.net (which covers all platforms, not only Mac OS X). Finally, to acknowledge where I originally found out about the mechanism: Read the Mac OS X specific part of the "How do I get JavaHL?" question in the JavaHL FAQ on subclipse.tigris.org.Solution 2: User-specific
Instead of creating a global, machine-wide Java extension, you can also create one that works for just one user. Log in as that user, open a terminal window and type the following:
mkdir -p ~/Library/Java/Extensions # do this only if the folder does not exist cd ~/Library/Java/Extensions ln -s /sw/lib/svn15/libsvnjavahl-1.jnilib .
The only difference to the global solution 1 is that you do everything inside the user's home directory, represented by the "~" character that prepends all paths in this example. Note that this solution still affects every Java application (including all instances of Eclipse) launched by that single user.
You may like this solution because
- you don't have admin rights on your machine (how did you get Fink installed in the first place?)
- you don't want to impose a global solution on unsuspecting users
Solution 3: Eclipse-specific
The following rather ugly hack is an Eclipse-specific solution:
cd /Applications/eclipse/Eclipse.app/Contents/MacOS mv eclipse eclipse-bin vi eclipse # do some editing, save the file chmod +x eclipse
This effectively replaces the Eclipse launcher binary with a shell script. This is what the new launcher script should contain:
!/bin/bash if test -z "$DYLD_LIBRARY_PATH"; then export DYLD_LIBRARY_PATH="/sw/lib/svn15" else export DYLD_LIBRARY_PATH="$DYLD_LIBRARY_PATH:/sw/lib/svn15" fi $(dirname "$0")/eclipse-bin
Note: For reasons unkown to me, it is not possible to use
DYLD_FALLBACK_LIBRARY_PATH. If the fallback variable is used, Subclipse will simply not find JavaHL.
You may like this solution because
- you don't want a solution that might have unwanted/unexpected effects on innocent Java applications (innocent = not Eclipse)
- it affects only a single Eclipse installation, but you would like to have multiple Eclipse installations with different configurations
- the shell script is sufficiently robust so that the Eclipse folder (which contains the .app bundle) can be moved around, e.g. to
What didn't work for me
One hint on the subclipse-users mailing list from October 2008 suggests editing
/Applications/eclipse/Eclipse.app/Contents/MacOS/eclipse.ini and adding the following line:
This simply has no effect in my environment, i.e. Subclipse will simply not find JavaHL.
What also didn't work for me was the solution outlined in the package description of
svn-javahl (try "
fink describe svn-javahl"): This solution basically involves copying a file into and creating a symlink inside the folder of the Subclipse core plugin (somewhere inside
/Applications/eclipse/plugins). The problem I had was that in my environment the core plugin exists only as a .jar file, not as a folder, and that I was unable to "convert" the .jar file into a folder. Unable = I am a wimp when it comes to Eclipse/Java "internals" and I simply don't know enough for successful "conversion".
Eclipse crashes with "old" versions of svn-javahl
As I already mentioned at the beginning of this article, Eclipse may crash if you try one of the above solutions while you have an "old" version of the
svn-javahl package installed. "Old" in this case means: Older than 1.6.5-2. My first attempts were made with 1.6.5-1, and with this version I definitely had crashes due to unresolved symbols. An abridged version of the crash report looks like this:
[...] Exception Type: EXC_BREAKPOINT (SIGTRAP) Exception Codes: 0x0000000000000001, 0x000000008fe0105c Crashed Thread: 0 [...] Dyld Error Message: Symbol not found: _svn_dso_initialize2 Referenced from: /sw/lib/svn15/libsvnjavahl-184.108.40.206.dylib Expected in: dynamic lookup
The difference between the package versions 1.6.5-1 and 1.6.5-2 is the fix Daniel Johnson added precisely to prevent this unresolved symbol error.
Finally, a short overview of my system setup is probably in order, to make it clear that I have been using mostly the latest versions of everything. Your results may be different if you use other versions, especially earlier versions of Eclipse and/or Subclipse.
- Mac OS X 10.5.8 on a dual G5
- Developer Tools with Xcode 3.1.3
- fink --version
- Package manager version: 0.29.10
- Distribution version: selfupdate-rsync Thu Oct 1 08:20:29 2009, 10.5, powerpc
- Fink package svn-javahl 1.6.5-2
- Eclipse Galileo (3.5)
- Subclipse 1.6