I’m trying to use the msbuild plugin. It mostly works, but for some reason when it runs in our jenkins windows slave, it falls over saying:
Caused by: java.lang.NoClassDefFoundError: Could not initialize class com.sun.jna.Native
at com.sun.jna.Memory.malloc(Memory.java:691)
at com.sun.jna.Memory.<init>(Memory.java:90)
at com.sun.jna.ptr.ByReference.<init>(ByReference.java:33)
at com.sun.jna.platform.win32.WinReg$HKEYByReference.<init>(WinReg.java:41)
at com.sun.jna.platform.win32.WinReg$HKEYByReference.<init>(WinReg.java:37)
at com.sun.jna.platform.win32.Advapi32Util.registryGetStringValue(Advapi32Util.java:540)
at com.sun.jna.platform.win32.Advapi32Util$registryGetStringValue.call(Unknown Source)
at com.ullink.Registry.getValue(Registry.groovy:49)
at com.ullink.Registry$getValue.call(Unknown Source)
at com.ullink.Msbuild.trySetMsbuild(Msbuild.groovy:96)
at com.ullink.Msbuild$_closure1.doCall(Msbuild.groovy:40)
at com.ullink.Msbuild.<init>(Msbuild.groovy:39)
at com.ullink.Msbuild_Decorated.<init>(Unknown Source)
at org.gradle.api.internal.DependencyInjectingInstantiator.newInstance(DependencyInjectingInstantiator.java:62)
at org.gradle.api.internal.ClassGeneratorBackedInstantiator.newInstance(ClassGeneratorBackedInstantiator.java:36)
at org.gradle.api.internal.project.taskfactory.TaskFactory$1.call(TaskFactory.java:124)
(This is with Gradle 1.12 executed using the wrapper).
Various attempts to debug the issue using -Djna.debug=true, -Djna.debug.jna=true didn’t work, as the old version of JNA included in the gradle distribution doesn’t support that option.
Turns out that JNA is picking up the jnidispatch.dll included in the gradle distribution, but the plugin was attempting to load a newer version (3.5.0). The plugin has some code which attempts to work around this, but for some reason that I haven’t been able to determine, when executing under jenkins it wouldn’t work, and the above exception would be thrown.
My workaround in the end has been to exclude all transitive dependencies from the plugin (it pulls in the jna platform library as well), pull in jna and jna-platform 4.1.0 and then force JNA to not use the DLL in the gradle dist by setting System.properties[‘jna.boot.library.name’] to something nonexistent. I can’t even do that in the version of JNA that gradle ships with, as that option isn’t supported in 3.2.7 either.
My suggestion is to bump the version of JNA that gradle ships with to the most recent release (4.1.0). This should pick up any bugfixes that have come in since 3.2.7 which is almost 4 years old now, and that version allows workarounds like the above when necessary, should a plugin need a later version in the future.
Seems like before 2.0 would be the time to bump a dep like this, but it may be a bit late in the day…
Cheers
Tom