Integrating Fink's svn-javahl package and Subclipse

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 /Developer/Applications.

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: 

-Djava.library.path=/sw/lib/svn15

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-1.0.0.0.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.

System overview

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

Comments

Anonymous

2009-10-13T20:33:55+02:00

Unfortunately, this tip

Unfortunately, this tip doesn't work for those who are using Fink bootstrapped for 64 bits.

file /sw/lib/svn15/libsvnjavahl-1.jnilib /sw/lib/svn15/libsvnjavahl-1.jnilib: Mach-O 64-bit dynamically linked shared library x86_64

only libsvnjavahl-1.jnilib would work so far with Eclipse.

Alan

Anonymous

2009-10-13T20:35:35+02:00

Sorry, amending: only

Sorry, amending:

only libsvnjavahl-1.jnilib 32 bits would work so far with Eclipse.

patrick

2009-11-03T16:49:47+01:00

I guess

Without researching the issue, I guess that a 64bit build of Eclipse is required to use libraries built with 64bit. As an alternative, you could try to install the Subversion package provided by openCollabNet - the package includes JavaHL and provides both 32 and 64 bit builds. If I remember correctly, the package installs into /opt and uses the "Java Extensions" mechanism you've seen in my article.

BTW - congratulations, you have posted the first comment on this website :-)

Glenn

2010-10-20T05:14:25+02:00

Solution 1 worked for me, 64 bit

I'm running Snow Leopard.

I ran "fink install svn-javahl" with 64-bit fink and then made the link as described in Solution 1. Then in Eclipse Galileo (3.5.2, 64-bit), in Preferences > Team > SVN > SVN interface Client: I selected JavaHL (JNI) 1.6.13 r1002816.

Then I right-clicked on a project, selected Team > Share Project..., and it worked.