mvn test of jenkins plugins failed with libjna-java installed

[Jean-Baptiste Lallement]

Quantal up to date

TEST CASE:
1. Install maven and libjna-java
2. Setup a basic plugin for jenkins (https://wiki.jenkins-ci.org/display/JENKINS/Plugin+tutorial)
3. cd to the project directory and run:
  $ mvn test
=> Verify that test failed
4. Uninstall libjna-java
5. Run: mvn test
=> Verify that test passed

ACTUAL RESULT
With libjna-java mvn test failed with
java.lang.UnsatisfiedLinkError: com.sun.jna.Native.open(Ljava/lang/String;)J
 at com.sun.jna.Native.open(Native Method)
 at com.sun.jna.NativeLibrary.getInstance(NativeLibrary.java:236)
 at com.sun.jna.Library$Handler.<init>(Library.java:140)
 at com.sun.jna.Native.loadLibrary(Native.java:366)
 at com.sun.jna.Native.loadLibrary(Native.java:351)
 at hudson.util.jna.GNUCLibrary.<clinit>(GNUCLibrary.java:105)

This is really annoying because libjna-java is a dependency of jenkins-common, which prevent building plugins for Jenkins on the same machine the server is installed on.

WORKAROUND
Add the following lines to your project's pom.xml

<dependency>
    <groupId>net.java.dev.jna</groupId>
    <artifactId>jna</artifactId>
    <version>3.2.2</version>
</dependency>

If you want to use 3.4.0 instead, update the version in pom.xml and run maven with:
$ mvn -DargLine="-Djna.nosys=true" test

ProblemType: Bug
DistroRelease: Ubuntu 12.10
Package: libjna-java 3.2.7-4
ProcVersionSignature: Ubuntu 3.5.0-17.28-generic 3.5.5
Uname: Linux 3.5.0-17-generic x86_64
ApportVersion: 2.6.1-0ubuntu3
Architecture: amd64
Date: Wed Oct 10 22:59:45 2012
ProcEnviron:
 TERM=xterm
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: libjna-java
UpgradeStatus: Upgraded to quantal on 2012-01-31 (252 days ago)

[Jean-Baptiste Lallement (jibel)]

Result of mvn test

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Marius Gedminas (mgedmin)]

This is still a problem in Ubuntu 15.10: https://github.com/jenkinsci/embeddable-build-status-plugin/pull/17#issuecomment-156210562

(Although I'm not sure "still" is the right word -- it worked for me before, in 15.04, unless I'm mistaken, and then regressed.)

[Jesse Glick (jesse-glick)]

It is unfortunate that JNA defaults to looking in a system location for libjnidispatch.so, since that means that non-packaged Java applications which happen to put a different version in their classpath will pick up the wrong binary. You should need to opt in to using the system library. For purposes of this package I would suggest that the DLL be moved, and packages depending on this one which wish to use it should add that location to $LD_LIBRARY_PATH. (If they neglect to do so, the worst that happens is that JNA unpacks its bundled DLL into a temporary directory at runtime, with a small performance penalty.)

[Matthias Klose (doko)]

well, the distro should work by default. Why can't JNA be teached to look up libjnidispatch.so in the classpath?

[Emmanuel Bourg (ebourg)]

@doko It does actually, that's the purpose of the jna.nosys property. When set to true JNA will skip the library path and look only into its classpath.

A simple workaround would be to rename the libjnidispatch.so file installed by the libjna-jni package (libjnidispatch-debian.so for example). Thus the packaged JNA would never conflict with other incompatible JNA jars used on the system, even when the jna.nosys property isn't specified.

[Launchpad Janitor (janitor)]

This bug was fixed in the package libjna-java - 4.2.2-1

---------------
libjna-java (4.2.2-1) unstable; urgency=medium

  * Team upload.
  * New upstream release
  * Renamed the native library to avoid conflicts with other JNA jars used
    on the system (LP: #1065253)
  * Improved the reproducibility:
    - Use the year of the source date in the copyright notice of the javadoc
  * Standards-Version updated to 3.9.7 (no changes)
  * Use secure Vcs-* fields
  * Call dh_installchangelogs only once during the build

 -- Emmanuel Bourg <email address hidden> Wed, 23 Mar 2016 13:45:27 +0100