3.1-beta1 jars seem badly broken

Troubleshooting
1

Not sure if this is a bug, or just an oversight on my part, but it sure feels like a bug to me.

I’m seeing missing dependencies for NiftyGUI, as well as missing bulletjme native libs for the Bullet lib.

To reproduce the NiftyGUI issue:

  1. git clone https://github.com/zharvey-welltok/jme3-jar-example.git (link for the repo is here)
  2. Navigate to that root directory (jme3-jar-example)
  3. Run ./gradlew run

You’ll get console output that looks like:

Could not resolve all dependencies for configuration ':compileClasspath'.
> Could not find lessvoid:nifty-default-controls:1.4.1.
  Searched in the following locations:
      https://repo1.maven.org/maven2/lessvoid/nifty-default-controls/1.4.1/nifty-default-controls-1.4.1.pom
      https://repo1.maven.org/maven2/lessvoid/nifty-default-controls/1.4.1/nifty-default-controls-1.4.1.jar
      https://jcenter.bintray.com/lessvoid/nifty-default-controls/1.4.1/nifty-default-controls-1.4.1.pom
      https://jcenter.bintray.com/lessvoid/nifty-default-controls/1.4.1/nifty-default-controls-1.4.1.jar
  Required by:
      bimderboo:jme3-jar-example:unspecified > org.jmonkeyengine:jme3-niftygui:3.1.0-beta1
> Could not find lessvoid:nifty-style-black:1.4.1.
  Searched in the following locations:
      https://repo1.maven.org/maven2/lessvoid/nifty-style-black/1.4.1/nifty-style-black-1.4.1.pom
      https://repo1.maven.org/maven2/lessvoid/nifty-style-black/1.4.1/nifty-style-black-1.4.1.jar
      https://jcenter.bintray.com/lessvoid/nifty-style-black/1.4.1/nifty-style-black-1.4.1.pom
      https://jcenter.bintray.com/lessvoid/nifty-style-black/1.4.1/nifty-style-black-1.4.1.jar
  Required by:
      bimderboo:jme3-jar-example:unspecified > org.jmonkeyengine:jme3-niftygui:3.1.0-beta1
> Could not find lessvoid:nifty:1.4.1.
  Searched in the following locations:
      https://repo1.maven.org/maven2/lessvoid/nifty/1.4.1/nifty-1.4.1.pom
      https://repo1.maven.org/maven2/lessvoid/nifty/1.4.1/nifty-1.4.1.jar
      https://jcenter.bintray.com/lessvoid/nifty/1.4.1/nifty-1.4.1.pom
      https://jcenter.bintray.com/lessvoid/nifty/1.4.1/nifty-1.4.1.jar
  Required by:
      bimderboo:jme3-jar-example:unspecified > org.jmonkeyengine:jme3-niftygui:3.1.0-beta1

Then, to reproduce the Bullet issue, comment out the NiftyGUI dependency inside build.gradle (so, line 37) so that we can move past the NiftyGUI issue for the time being (afterall, this example repo doesn’t actually use any NiftyGUI code).

Then re-run ./gradlew run and you’ll get (on Mac OS El Capitan 10.11.5):

Oct 10, 2016 4:07:11 AM com.jme3.system.JmeDesktopSystem initialize
INFO: Running on jMonkeyEngine 3.1-beta1
 * Branch: HEAD
 * Git Hash: 310f4db
 * Build Date: 2016-04-25
Exception in thread "main" java.lang.UnsatisfiedLinkError: The required native library 'bulletjme' was not found in the classpath via 'native/osx/x86_64/libbulletjme.dylib'. Error message: no bulletjme in java.library.path
	at com.jme3.system.NativeLibraryLoader.loadNativeLibrary(NativeLibraryLoader.java:593)
	at com.jme3.system.JmeDesktopSystem.initialize(JmeDesktopSystem.java:348)
	at com.jme3.system.JmeDesktopSystem.newContext(JmeDesktopSystem.java:271)
	at com.jme3.system.JmeSystem.newContext(JmeSystem.java:162)
	at com.jme3.app.LegacyApplication.start(LegacyApplication.java:461)
	at com.jme3.app.LegacyApplication.start(LegacyApplication.java:424)
	at com.jme3.app.SimpleApplication.start(SimpleApplication.java:125)
	at com.jme3.app.Application$start.call(Unknown Source)
	at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:48)
	at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:113)
	at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:117)
	at Library.main(Library.groovy:15)
:run FAILED

Any ideas as to what is going on here?

2

Ask “zharvey welltok”, “jme3-jar-example” wasn’t created by the jme team.

3

Not sure I follow that @normen… are you just stating for the record that my repo wasn’t created by the jme team (which I think is pretty obvious)? Or are you asking me a question?

4

Nifty is not available on any maven repo, we were publishing it on a private server but this server died.
so you have several option :

5

Also, you don’t include the native bullet dependency so it’s not really a surprise that you don’t have the native bullet dependency…

6

@nehon:

Jitpack seems like an interesting approach, but one quick question to that: isn’t Nifty open source?! If so, why not just put it in a Maven-compatible public repo (JCenter or otherwise)?

Also, any ideas about the native bullet lib? Frankly that’s more important + disconcerting to me.

@pspeed:

Typically jars that have native dependencies will ship with those dependencies and select them on the fly (doing OS detection at startup). If jME strays from this convention, and expects users to install native jars on their machines as upfront dependencies, then I guess that’s ok (although I don’t see how thats a reasonable expectation for end users - the game players) but then I’d ask for some documentation for how/where to install those native deps.

7

We are just nifty users and we are not involved in its development. We are not going to publish their stuff ourselves.

For the bullet native, we do have a native extraction thingy, but I’m not really familiar with it and I don’t really know why you have this issue.

8

You don’t even include the dependency. You only include the bullet INTERFACE to which one of the (either native or jbullet) implements.

Hint: bullet and native

And next time you want help debugging YOUR build issues… try not walking into the room shouting how everything is badly broken. Clearly there are plenty of people using these jars just fine.

9

@nehon:

We are just nifty users and we are not involved in its development. We are not going to publish their stuff ourselves.

Makes perfect sense - did not realize Nifty was separate from jme.

@pspeed:

You don’t even include the dependency. You only include the bullet INTERFACE to which one of the (either native or jbullet) implements.

Also makes perfect sense, thanks for clarifying.

And next time you want help debugging YOUR build issues… try not walking into the room shouting how everything is badly broken. Clearly there are plenty of people using these jars just fine.

No need to be so sensitive, I’m not shouting at anybody here. I thought I had found some broken dependencies and wanted to report them.

10

Your subject: “3.1-beta1 jars seem badly broken”

…which if that were true then no one would be using them.

I’m not being sensitive… just saying you’ll get better responses if you stick to your actual issues and don’t claim immediately that the problem is on our end. Because the logic that leads to that sort of subject is flawed no matter which way you look at it. a) either no one is using JME so help is unlikely, or b) the jars are fine and the problem is in the build configuration.

11

You didn’t say that this was your repo, you basically just said “look at this repo, it throws errors when trying to build it!”

12

To add something useful:
Nifty was always available through maven, the old version was accessible through some sourceforge hosted repo and the latest releases should be available on maven central:

<groupId>com.github.nifty-gui</groupId>
<artifactId>nifty</artifactId>
<version>1.4.2</version>
3 Likes
13

Oh ok, nice to know , thanks @Darkchaos

14

Since jitpack has been pulled on the table… why isn’t jitpack treated as an official release? What’s different from a release on jcenter (assuming that the project has some stable branch and that it build an artifact)?

15

That one is expecially made with confirmation (eg. I guess my code is bug free) while the other will just grab and tape it together.