Upgrade JDeveloper 10.1.3.3 to work with Subversion 1.6

I wanted to upgrade my Subversion server and client to version 1.6, but what was holding me back was the fear that JDeveloper 10.1.3.3 would no longer be able to access my repository. When I finally got a block of time to play around with it, the mechanics of it turned out to be relatively easy.

The first step was to update my Subversion server and client. The client, unfortunately, is necessary because the JDeveloper interface is limited to basic version control operations. Even then, it doesn't support some necessary corrective actions as files are modified and moved around. I use HTTP as my transport protocol of choice, so see my previous post for how I made an easy task difficult by disengaging my brain :-P.

The next step was about as painless as it gets in the Oracle world - updating JDeveloper's Subversion extension. Thanks to Aino Andriessen's blog, Upgrade JDeveloper 10g Subversion client, on the AMIS Technology web site, I already had a blueprint of how to make JDev work with Subversion 1.5. The same works for 1.6. Since recent incarnations of JDeveloper rely on the SVNKit for its Subversion extension, I simply had to replace a few libraries.

1. Make sure JDeveloper is shut down.
2. Download the Standalone Version of SVNKit from the SVNKit web site. The latest version available when I got mine was 1.3.1.
3. Extract the svnkit-javahl.jar and svnkit.jar files from the archive.
4. Rename svnkit-javahl.jar to svnjavahl.jar.
   
5. Copy the two JAR files to your JDeveloper extensions directory, [JDevRoot]/jdev/extensions/oracle.jdeveloper.subversion.10.1.3, replacing the existing files.
   
6. Restart JDeveloper. If it starts without error, that's a good sign (see below).
   
7. Open Tools->Preferences... then expand the Versioning->Subversion category to verify JDev recognized the new client libraries. Mine showed:


  Subversion client:

    SVN/1.6.5 SVNKit/1.3.1 (http://svnkit.com.) r6109

That's all there is. Now you can access your updated repositories from within JDeveloper.

For what it's worth, I did run into a minor problem the first time. I forgot to copy the updated svnkit.jar. When I tried to start JDeveloper, it failed with an exception because a JavaHL function was trying to use one of the new classes in it that it obviously couldn't find. Copying both library files solved the problem. Here is the exception I got, with a bit of the stack trace:


java.lang.NoClassDefFoundError: org/tmatesoft/svn/core/internal/util/SVNHashMap

at org.tigris.subversion.javahl.JavaHLObjectFactory.<clinit>(JavaHLObjectFactory.java:69)

at org.tmatesoft.svn.core.javahl.SVNClientImpl$1.handleStatus(SVNClientImpl.java:170)

at org.tmatesoft.svn.core.internal.wc.SVNStatusEditor.sendUnversionedStatus(SVNStatusEditor.java:315)

at org.tmatesoft.svn.core.internal.wc.SVNStatusEditor.getDirStatus(SVNStatusEditor.java:189)

at org.tmatesoft.svn.core.internal.wc.SVNStatusEditor.closeEdit(SVNStatusEditor.java:114)

...



Updating to Subversion 1.6.5

I recently attempted to install version 1.6.5 of Subversion on my Solaris 10 server. Everything would have gone very smoothly, but one of my synapses misfired and took me on an unwelcome detour for a couple hours. When it was over, I was embarrassed, but instead of hiding my head in the screen, I put my (brief) story out here so you can learn from my mistake. The other reason is because the particular error I had to diagnose was almost non-existent in Internet searches.

Here was my situation: I had been using Subversion 1.4.5 for about a year or so, but it was growing long in the tooth and some of my development tool updates were looking for a more current version to work with. After doing a little research, I decided to plunge into the latest release of Subversion and get all my Subversion-aware tools updated.

My server ran Solaris 10, so I searched a favorite site, sunfreeware.com, to see if I could get a binary Subversion package and avoid the tedium of compiling it myself. I found it there and proceeded to check its dependencies on other packages. It required the latest, greatest Apache server 2.2.14. No big deal, I thought. OK, in addition to an Apache update, there were about ten other packages I had to replace first. I did that. So far, so good. Now grab Apache.

I was already running version 2.2.6, so I didn't need to change anything...well maybe a few things. I needed to make a backup of my customized files so I didn't overwrite anything. I tarred up my conf, htdocs, icons, lib, modules, and smf (Solaris service management facility files) directories and saved them to a place that wouldn't get lost. Now I downloaded the Apache 2.2.14 package and installed it. Everything was going smooth as silk. Now restore my customized files and install Subversion 1.6.5. Great. Fire it up.

Oops. Mistake! The new Apache came with a whole lot of new libraries and modules recompiled for the update. When I restored my customizations, I clobbered most of the new libraries and modules. When I attempted to start Apache, I was getting what I thought was a Subversion error. I had to dig into the startup log, in my case /var/svc/log/network-http:apache2.log. I found this message:


[ Oct 14 20:06:24 Executing start method ("/lib/svc/method/http-apache2 start") ]

httpd: Syntax error on line 526 of /usr/local/apache2/conf/httpd.conf: Syntax error on line 6 of /usr/local/www/conf/extra/httpd-subversion.conf: Cannot load /usr/local/www/modules/mod_dav_svn.so into server: ld.so.1: httpd: fatal: relocation error: file /usr/local/lib/libsvn_subr-1.so.0: symbol apr_memcache_getp: referenced symbol not found

[ Oct 14 20:06:24 Method "start" exited with status 1 ]



Really confusing, because the dynamic libraries it was complaining about were already installed. So why couldn't it find the missing symbol. I hunted through the Apache and Subversion web sites and found out the latest Apache also used the latest (within days) Apache Portable Runtime libraries. But they were supposed to be bundled with Apache. What was wrong?

"PEBCAK!" was my answer. When I restored my customizations I overwrote the new libraries with the ones I had from Apache 2.2.6, obliterating the functions required by the new Subversion (and eventually, Apache). Reinstalling the Apache 2.2.14 package and selectively restoring only my conf and htdocs directories fixed the error.

Just shows how casual thinking - Oh, look! A simple update! - can get you into trouble. If you found this post useful and it saved you some time, drop me a comment. I'd like to know my self-inflicted aggravation spared someone else's.

Some days it is best just to sit back, take a deep breath, and just laugh at yourself!