jinput finds no controllers ... only in production version?

github project: https://www.github.com/marginallyclever/robot-overlord/

The 1.6.1 release believes there are no controllers of any kind in the system.  When I run in debug mode through Eclipse it finds them no trouble.  In release ControllerEnvironment.getDefaultEnvironment().getControllers().length is 0.

The jinput libraries are all in the with-dependencies JAR file and ControllerEnvironment.getDefaultEnvironment().isSupported() is true.

Any idea what I've missed?

Hello

Actually, we just accepted a few patches but we don't actively maintain JInput. At the very beginning, we planned to integrate it somehow into JogAmp but I further decided not to do so, I'd prefer improving NEWT without relying on this library (I've being working for weeks in trying to support libinput under GNU Linux as a first step).

In my humble opinion, something is wrong in your environment, you probably don't use the same library when you debug and when you don't.

I didn't even notice the problem until I started getting bug reports from users on other machines.  So... their environments are also borked?

I see that the root folder of my github project has the various dlls and - when they are there - the application runs ok.  those same native libraries are in the root of the jar file but they're .. not on the classpath?  so they silently fail to load and then input doesn't work.

I really want to believe it has something to do with how the natives are unpacked.  right now it will work if the natives are adjacent to the jar file and won't work if they are IN the jar file.  ... and yet jogl natives are loaded no problem.

JInput doesn't have the same layout than JogAmp libraries, keep it in mind. You have to set the Java library path.

Ok... please forgive my ignorance.  Is there a way in maven to have that set automatically when a user runs the jar file?

Does your application use a launcher, or are your users just double-clicking on the jar?

If the first, the launcher may be what sets up the classpath.

If the second, you'll want to look at the part of the maven build that generates the manifest file, and modify accordingly. (Once you find the right spot, it should be pretty obvious)

No you can't modify the Java library path (not the classpath) in the manifest file. You must use "-Djava.library.path", the path is OS specific.

The Java library path can be set at runtime programmatically but it's a hack, it might break:
http://web.archive.org/web/20160214203937/http://blog.cedarsoft.com/2010/11/setting-java-library-path-programmatically/

I use maven-nativedependencies-plugin but I don't know whether it still works.

By the way, if you use a single "executable" JAR without a real launcher, please keep in mind that it has numerous limitations as I explained here:
https://gouessej.wordpress.com/2014/11/22/ardor3d-est-mort-vive-jogamps-ardor3d-continuation-ardor3d-is-dead-long-life-to-jogamps-ardor3d-continuation/#executablejar