[SCM] svnclientadapter packaging branch, master, updated. debian/0.9.100-1-3-g7b699a6

Jakub Adam jakub.adam at ktknet.cz
Wed Oct 5 22:00:46 UTC 2011


The following commit has been merged in the master branch:
commit 7b699a629ae59ed8adaa2ddb39f8ae000f407575
Author: Jakub Adam <jakub.adam at ktknet.cz>
Date:   Tue Oct 4 22:43:16 2011 +0200

    Fix for compatibility with eclipse-subclipse
    
    We should avoid calling System.loadLibrary() for JavaHL native binaries in this
    package. Eclipse has a limitation that one JNI library can't be loaded by multiple
    bundles at once.
    
    If we load libsvnjavahl-1.so at JhlClientAdapterFactory.isAvailable(), another
    attempt, that is performed upon instantiating of SVNClient from JavaHL bundle,
    causes that UnsatisfiedLinkError is thrown. I removed the code that checks
    availability of native library from JhlClientAdapterFactory, as it mostly
    duplicates functionality of org.tigris.subversion.javahl.NativeResources. Now
    there is only single place where JNI library is loaded and the above described
    problem does not apply to us.
    
    Original binary distribution of Subclipse doesn't have this problem because
    upstream bundles SvnClientAdapter and JavaHL together with some Subclipse
    specific code into a single Eclipse plugin. It showed only after I removed the
    repeating code and tried to use libraries already present in Debian instead.

diff --git a/debian/changelog b/debian/changelog
index c210713..824d6c6 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -5,6 +5,7 @@ svnclientadapter (0.9.100-2) unstable; urgency=low
 
   [ Jakub Adam ]
   * Add OSGi metadata to JAR manifest
+  * Fix compatibility with eclipse-subclipse
 
  -- Andres Mejia <amejia at debian.org>  Sun, 17 Jul 2011 14:25:29 -0400
 
diff --git a/debian/patches/series b/debian/patches/series
index 8ec5961..5bce1dd 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,2 +1,3 @@
 packaging-changes.patch
 add-osgi-metadata.patch
+subclipse-load-nativelib-from-single-bundle.patch
diff --git a/debian/patches/subclipse-load-nativelib-from-single-bundle.patch b/debian/patches/subclipse-load-nativelib-from-single-bundle.patch
new file mode 100644
index 0000000..62012fc
--- /dev/null
+++ b/debian/patches/subclipse-load-nativelib-from-single-bundle.patch
@@ -0,0 +1,133 @@
+From: Jakub Adam <jakub.adam at ktknet.cz>
+Date: Tue, 4 Oct 2011 22:38:45 +0200
+Subject: subclipse-load-nativelib-from-single-bundle.patch
+
+We should avoid calling System.loadLibrary() for JavaHL native binaries in this
+package. Eclipse has a limitation that one JNI library can't be loaded by multiple
+bundles at once.
+
+If we load libsvnjavahl-1.so at JhlClientAdapterFactory.isAvailable(), another
+attempt, that is performed upon instantiating of SVNClient from JavaHL bundle,
+causes that UnsatisfiedLinkError is thrown. I removed the code that checks
+availability of native library from JhlClientAdapterFactory, as it mostly
+duplicates functionality of org.tigris.subversion.javahl.NativeResources. Now
+there is only single place where JNI library is loaded and the above described
+problem does not apply to us.
+
+Original binary distribution of Subclipse doesn't have this problem because
+upstream bundles SvnClientAdapter and JavaHL together with some Subclipse
+specific code into a single Eclipse plugin. It showed only after I removed the
+repeating code and tried to use libraries already present in Debian instead.
+
+---
+ .../javahl/JhlClientAdapterFactory.java            |   95 +++++---------------
+ 1 files changed, 21 insertions(+), 74 deletions(-)
+
+diff --git a/src/javahl/org/tigris/subversion/svnclientadapter/javahl/JhlClientAdapterFactory.java b/src/javahl/org/tigris/subversion/svnclientadapter/javahl/JhlClientAdapterFactory.java
+index f3108a4..2d76836 100644
+--- a/src/javahl/org/tigris/subversion/svnclientadapter/javahl/JhlClientAdapterFactory.java
++++ b/src/javahl/org/tigris/subversion/svnclientadapter/javahl/JhlClientAdapterFactory.java
+@@ -203,81 +203,28 @@ public class JhlClientAdapterFactory extends SVNClientAdapterFactory {
+     		}
+     		//workaround to solve Subclipse ISSUE #83
+     		available = false;
+-    		try {
+-    			/*
+-    			 * see if the user has specified the fully qualified path to the native
+-    			 * library
+-    			 */
+-    			try
+-    			{
+-    				String specifiedLibraryName =
+-    					System.getProperty("subversion.native.library");
+-    				if(specifiedLibraryName != null) {
+-    					System.load(specifiedLibraryName);
+-    					available = true;
+-    				}
+-    			}
+-    			catch(UnsatisfiedLinkError ex)
+-    			{
+-    				javaHLErrors.append(ex.getMessage()).append("\n");
+-    			}
+-    			if (!available) {
+-    				/*
+-    				 * first try to load the library by the new name.
+-    				 * if that fails, try to load the library by the old name.
+-    				 */
+-    				try
+-    				{
+-    					System.loadLibrary("libsvnjavahl-1");
+-    				}
+-    				catch(UnsatisfiedLinkError ex)
+-    				{
+-    					javaHLErrors.append(ex.getMessage() + "\n");
+-    					try
+-    					{
+-    						System.loadLibrary("svnjavahl-1");
+-    					}
+-    					catch (UnsatisfiedLinkError e)
+-    					{
+-    						javaHLErrors.append(e.getMessage()).append("\n");
+-    						System.loadLibrary("svnjavahl");
+-    					}
+-    				}
+ 
+-    				available = true;
+-    			}
+-    		} catch (Exception e) {
+-    			available = false;
+-    			javaHLErrors.append(e.getMessage()).append("\n");
+-    		} catch (UnsatisfiedLinkError e) {
+-    			available = false;
+-    			javaHLErrors.append(e.getMessage()).append("\n");
+-    		} finally {
+-    			availabilityCached = true;
+-    		}
+-    		if (!available) {
+-    			String libraryPath = System.getProperty("java.library.path");
+-    			if (libraryPath != null)
+-    				javaHLErrors.append("java.library.path = " + libraryPath);
+-    			// System.out.println(javaHLErrors.toString());
+-    		} else {
+-    			// At this point, the library appears to be available, but
+-    			// it could be too old version of JavaHL library.  We have to try
+-    			// to get the version of the library to be sure.
+-    			try {
+-	                SVNClientInterface svnClient = new SVNClient();
+-    				Version version = svnClient.getVersion();
+-    				if (version.getMajor() == 1 && version.getMinor() == 6)
+-    					available = true;
+-    				else {
+-    					available = false;
+-    					javaHLErrors = new StringBuffer("Incompatible JavaHL library loaded.  1.6.x or later required.");
+-    				}
+-    			} catch (UnsatisfiedLinkError e) {
+-    				available = false;
+-    				javaHLErrors = new StringBuffer("Incompatible JavaHL library loaded.  1.6.x or later required.");
+-    			}
+-    		}
++			// At this point, the library appears to be available, but
++			// it could be too old version of JavaHL library.  We have to try
++			// to get the version of the library to be sure.
++			try {
++				SVNClientInterface svnClient = new SVNClient();
++				Version version = svnClient.getVersion();
++				if (version.getMajor() == 1 && version.getMinor() == 6)
++					available = true;
++				else {
++					available = false;
++					javaHLErrors = new StringBuffer("Incompatible JavaHL library loaded.  1.6.x or later required.");
++				}
++			} catch (UnsatisfiedLinkError e) {
++				available = false;
++				javaHLErrors = new StringBuffer(e.getMessage());
++			} catch (LinkageError e) {
++				available = false;
++				javaHLErrors = new StringBuffer("Incompatible JavaHL library loaded.  1.6.x or later required.");
++			} finally {
++				availabilityCached = true;
++			}
+     	}
+ 
+     	return available;
+-- 

-- 
svnclientadapter packaging



More information about the pkg-java-commits mailing list