Custom Gradle Plugin using JNA 3.4.0 with AntBuilder

Help/Discuss
1

Hello out there,

I have tried for the last two days to write custom plugin for gradle that internally uses the JNA Library.
The main implementation of the plugin was written for ANT so I use the AntBuilder to create the Ant Task and call it as written in the documentation.
Unfortunatly when the ant task tries to load the JNA Library I get the Error

* What went wrong:
Execution failed for task ':checkSchemaFull'.
> java.lang.Error: 
  
  There is an incompatible JNA native library installed on this system.
  To resolve this issue you may do one of the following:
   - remove or uninstall the offending library
   - set the system property jna.nosys=true
   - set jna.boot.library.path to include the path to the version of the 
     jnidispatch library included with the JNA jar file you are using

After some hours of debugging in the jna library I’ve found that gradle is setting the system property jna.boot.library.path to $GRADLE_USER_HOME/native/ where the native dll (on windows) in the version 3.2.2. lives. That leads to the error in my ant task when it tries to load the 3.4.0 version of JNA, because the versions do not match.
I’ve tried setting the jna.boot.library.path from the command line and from within the gradle.properties of my project, with no success.

The only working solution is to call System.setProperty("jna.boot.library.path","") manually before calling the ant task in my plugin and restore it after the execution.
So my questions are now:

  1. Is this the only solution or am I missing somewhat?
  2. Why does gradle sets the system property for jna.
  3. Is it possible to fork the ant task to a dedicated java process, so it’s save to change the system property with minimal side effect?
2
  1. This is the only solution I am aware of at the moment aside from 3.
  2. Gradle uses JNA for terminal integration on windows only. It doesn’t use it at all on other platforms.
  3. You can certainly fork an ant process using JavaExec or Exec. It won’t have the same level of integration with gradle (e.g. you wouldn’t have the ant object to access things like ant properties set by the task), but if this isn’t necessary for you, then that’s a reasonable solution.