mvn test of jenkins plugins failed with libjna-java installed

Bug #1065253 reported by Jean-Baptiste Lallement on 2012-10-10
This bug affects 3 people
Affects Status Importance Assigned to Milestone
libjna-java (Ubuntu)

Bug Description

Quantal up to date

1. Install maven and libjna-java
2. Setup a basic plugin for jenkins (
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

With libjna-java mvn test failed with
 at Method)
 at com.sun.jna.NativeLibrary.getInstance(
 at com.sun.jna.Library$Handler.<init>(
 at com.sun.jna.Native.loadLibrary(
 at com.sun.jna.Native.loadLibrary(
 at hudson.util.jna.GNUCLibrary.<clinit>(

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.

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


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
 PATH=(custom, no user)
SourcePackage: libjna-java
UpgradeStatus: Upgraded to quantal on 2012-01-31 (252 days ago)

Jean-Baptiste Lallement (jibel) wrote :
Jean-Baptiste Lallement (jibel) wrote :

Result of mvn test

description: updated
description: updated
Launchpad Janitor (janitor) wrote :

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

Changed in libjna-java (Ubuntu):
status: New → Confirmed
Marius Gedminas (mgedmin) wrote :

This is still a problem in Ubuntu 15.10:

(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) wrote :

It is unfortunate that JNA defaults to looking in a system location for, 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.)

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers