Application not closing cleanly unless I delete some elements #364

Closed
TripleSnail opened this Issue Aug 27, 2015 · 26 comments

Projects

None yet

4 participants

@TripleSnail

I migrated from nifty-gui 1.3.x to 1.4.1 and I'm experiencing a strange issue with this new version.

When I close my application, it doesn't get destroyed cleanly. Then I narrowed down the problem to the nifty-gui. When I deleted some elements by commenting them in XML, the application started closing cleanly. The strange thing is that it didn't seem to matter much which elements. Only the amount seemed to matter. Removing screen (with lot of elements) made it work. Removing some text-elements made it work.

Here is the XML-file I used:

https://github.com/TripleSnail/Arkhados/blob/jme31/assets/Interface/ClientUI.xml

@TripleSnail TripleSnail added a commit to TripleSnail/Arkhados that referenced this issue Aug 28, 2015
@TripleSnail TripleSnail Worked around issue where Client didn't close cleanly
Most of the content in the third credits panel has been disabled temporarily. I reported this issue here: nifty-gui/nifty-gui#364
b9a8650
@bgroenks96
Collaborator

Can you give a specific example of something you commented out to make the application close properly?

@TripleSnail

It has been a long time and I don't remember all the experiments, but this is one example from an old branch (now I just use System.exit to work around this issue).

https://github.com/TripleSnail/Arkhados/blob/jme31/assets/Interface/ClientUI.xml#L457

I commented some of those controls. But it's not related to them, because I was able to make app close cleanly by commenting bunch of other elements.

By the way, this issue seems to be exactly the same as this:

#365

I too use JMonkeyEngine 3.1 alpha and I was able to see that there were threads that didn't close.

@bgroenks96
Collaborator

See #365 for useful code and stack trace.

@bgroenks96
Collaborator

I don't think this is a Nifty issue, actually. Which Nifty backend is jME using? (or maybe @void256 will know)

The java.util.Timer API is not used anywhere in Nifty's codebase:
https://github.com/void256/nifty-gui/search?utf8=%E2%9C%93&q=java.util.Timer

@bgroenks96
Collaborator

That being said, there could be another facility or library Nifty is using that is launching a Timer instance. Unfortunately, there probably isn't much we can do about that here.

@bgroenks96 bgroenks96 closed this Feb 4, 2016
@tonihele

Here, this initiates it:

java.util.Timer.<init>()
org.bushe.swing.event.ThreadSafeEventService.startCleanup()
org.bushe.swing.event.ThreadSafeEventService.incWeakRefPlusProxySubscriberCount()
org.bushe.swing.event.ThreadSafeEventService.subscribe(java.lang.Object, java.util.Map, java.lang.Object)
org.bushe.swing.event.ThreadSafeEventService.subscribe(java.lang.Class, org.bushe.swing.event.EventSubscriber)
de.lessvoid.nifty.elements.render.TextRenderer.<init>(de.lessvoid.nifty.Nifty)
de.lessvoid.nifty.loaderv2.types.TextType$1.createElementRenderer(de.lessvoid.nifty.Nifty)
de.lessvoid.nifty.loaderv2.types.ElementType.internalCreateElement(de.lessvoid.nifty.elements.Element, de.lessvoid.nifty.Nifty, de.lessvoid.nifty.screen.Screen, de.lessvoid.nifty.layout.LayoutPart, de.lessvoid.xml.xpp3.Attributes, int)
de.lessvoid.nifty.loaderv2.types.ElementType.create(de.lessvoid.nifty.elements.Element, de.lessvoid.nifty.Nifty, de.lessvoid.nifty.screen.Screen, de.lessvoid.nifty.layout.LayoutPart, int)
de.lessvoid.nifty.loaderv2.types.ElementType.create(de.lessvoid.nifty.elements.Element, de.lessvoid.nifty.Nifty, de.lessvoid.nifty.screen.Screen, de.lessvoid.nifty.layout.LayoutPart)
de.lessvoid.nifty.loaderv2.types.ElementType.applyChildren(de.lessvoid.nifty.elements.Element, de.lessvoid.nifty.screen.Screen, de.lessvoid.nifty.Nifty)
de.lessvoid.nifty.loaderv2.types.ElementType.applyStandard(de.lessvoid.nifty.Nifty, de.lessvoid.nifty.screen.Screen, de.lessvoid.nifty.elements.Element)
de.lessvoid.nifty.loaderv2.types.ElementType.create(de.lessvoid.nifty.elements.Element, de.lessvoid.nifty.Nifty, de.lessvoid.nifty.screen.Screen, de.lessvoid.nifty.layout.LayoutPart, int)
de.lessvoid.nifty.loaderv2.types.ElementType.create(de.lessvoid.nifty.elements.Element, de.lessvoid.nifty.Nifty, de.lessvoid.nifty.screen.Screen, de.lessvoid.nifty.layout.LayoutPart)
de.lessvoid.nifty.loaderv2.types.ElementType.applyChildren(de.lessvoid.nifty.elements.Element, de.lessvoid.nifty.screen.Screen, de.lessvoid.nifty.Nifty)
de.lessvoid.nifty.loaderv2.types.ElementType.applyStandard(de.lessvoid.nifty.Nifty, de.lessvoid.nifty.screen.Screen, de.lessvoid.nifty.elements.Element)
de.lessvoid.nifty.loaderv2.types.ElementType.create(de.lessvoid.nifty.elements.Element, de.lessvoid.nifty.Nifty, de.lessvoid.nifty.screen.Screen, de.lessvoid.nifty.layout.LayoutPart, int)
de.lessvoid.nifty.loaderv2.types.ElementType.create(de.lessvoid.nifty.elements.Element, de.lessvoid.nifty.Nifty, de.lessvoid.nifty.screen.Screen, de.lessvoid.nifty.layout.LayoutPart)
de.lessvoid.nifty.loaderv2.types.ElementType.applyChildren(de.lessvoid.nifty.elements.Element, de.lessvoid.nifty.screen.Screen, de.lessvoid.nifty.Nifty)
de.lessvoid.nifty.loaderv2.types.ElementType.applyStandard(de.lessvoid.nifty.Nifty, de.lessvoid.nifty.screen.Screen, de.lessvoid.nifty.elements.Element)
de.lessvoid.nifty.loaderv2.types.ElementType.create(de.lessvoid.nifty.elements.Element, de.lessvoid.nifty.Nifty, de.lessvoid.nifty.screen.Screen, de.lessvoid.nifty.layout.LayoutPart, int)
de.lessvoid.nifty.loaderv2.types.ElementType.create(de.lessvoid.nifty.elements.Element, de.lessvoid.nifty.Nifty, de.lessvoid.nifty.screen.Screen, de.lessvoid.nifty.layout.LayoutPart)
de.lessvoid.nifty.loaderv2.types.ElementType.applyChildren(de.lessvoid.nifty.elements.Element, de.lessvoid.nifty.screen.Screen, de.lessvoid.nifty.Nifty)
de.lessvoid.nifty.loaderv2.types.ElementType.applyStandard(de.lessvoid.nifty.Nifty, de.lessvoid.nifty.screen.Screen, de.lessvoid.nifty.elements.Element)
de.lessvoid.nifty.loaderv2.types.ElementType.create(de.lessvoid.nifty.elements.Element, de.lessvoid.nifty.Nifty, de.lessvoid.nifty.screen.Screen, de.lessvoid.nifty.layout.LayoutPart, int)
de.lessvoid.nifty.loaderv2.types.ElementType.create(de.lessvoid.nifty.elements.Element, de.lessvoid.nifty.Nifty, de.lessvoid.nifty.screen.Screen, de.lessvoid.nifty.layout.LayoutPart)
de.lessvoid.nifty.loaderv2.types.ScreenType.create(de.lessvoid.nifty.Nifty, de.lessvoid.nifty.loaderv2.types.NiftyType, de.lessvoid.nifty.spi.time.TimeProvider)
de.lessvoid.nifty.loaderv2.types.NiftyType.create(de.lessvoid.nifty.Nifty, de.lessvoid.nifty.spi.time.TimeProvider)
de.lessvoid.nifty.Nifty.loadFromFile(java.lang.String)
de.lessvoid.nifty.Nifty.addXml(java.lang.String)
@tonihele

A subscriber thing...

@bgroenks96
Collaborator

Yeah that's an issue with EventBus (it's a very old, unsupported library). You might be able to find some hacky way to force kill the thread, but there really isn't much of anything we can do in Nifty to fix that.

The good news is that Nifty 2.0 uses MBassador instead, so this shouldn't be an issue.

@void256 void256 referenced this issue in michaelbushe/EventBus Mar 14, 2016
Open

Cleanup Timer prevents JVM shutdown? #4

@void256
Member
void256 commented Mar 14, 2016

I took a closer look and I can confirm that @bgroenks96 is right :/

The problem appears to be that org.bushe.swing.event.ThreadSafeEventService does use a Timer to cleanup ... some things ... in some cases ... that I don't fully understand. They are extensively documented in the JavaDoc of the ThreadSafeEventService class but I still don't complete understand when and how that Timer is running.

However, the main problem here is, that the Timer is created as a non-daemon thread and therefore prevents the JVM to exit.

Here is the corresponding part (line 2100 of that class):

   private void startCleanup() {
      synchronized(listenerLock) {
         if (cleanupTimer == null) {
            cleanupTimer = new Timer();     // THIS IS THE PROBLEM! We need a new Timer(true) here, I think
         } 
         if (cleanupTimerTask == null) {
            cleanupTimerTask = new CleanupTimerTask();
            cleanupTimer.schedule(cleanupTimerTask, 0L, cleanupPeriodMS);            
         }
      }
   }

The additional odd thing is, that in the JavaDoc of the class the original author says:

* Cleanup is not run in a daemon thread, and thus will not stop the JVM from exiting.

which is not correct and probably the reason for the problem.

I've created an issue for the EventBus project here: michaelbushe/EventBus#4

Maybe there is a way to actual get a fix for this problem after all :)

@bgroenks96
Collaborator

@void256 The project hasn't been touched in years. At this point, it would be better to just fork and fix it. The only crappy part is we would have to deploy our own version of it to central and use that instead of the original.

@void256
Member
void256 commented Mar 14, 2016

@bgroenks96 I'm aware of that. My pull request from 2014 has been ignored as well. Creating that issue is still the right way to at least give the original author a chance to respond.

Since the project is rather small (two packages) and will probably not see another regular release there is another solution besides what you said. We could just go ahead and put the sources directly into Nifty and fix the problem there! Brute force! But I think that's ok given the circumstances.

@void256 void256 reopened this Mar 27, 2016
@void256
Member
void256 commented Mar 27, 2016

I reopened the issue because I think we can do something about it (see comments above) .. and I'm actually about to do something about it - stay tuned ๐Ÿ˜‰

@void256 void256 added a commit that referenced this issue Mar 27, 2016
@void256 void256 chore: directly integrate org.bushe.eventbus-1.4 source
The original project appears to be not updated anymore. In issue #364
a problem in that lib has been raised that will need to be fixed.

Since we don't expect the original project to be updated anymore (or
at least not in the foreseeable future) we choose the brute force solution:
include the source of the eventbus project directly and then later fix
the issue with it in our codebase.

This commit is the first step: include the source into our codebase.

 #364: Application not closing cleanly unless I delete some elements
e8f1820
@void256 void256 added a commit that referenced this issue Mar 27, 2016
@void256 void256 fix: Eventbus: make the ThreadSafeEventService cleanupTimer a daemon
The Cleanup-Timer should not prevent ending the JVM so we've changed
it into a daemon thread.

 #364: Application not closing cleanly unless I delete some elements
3a1a5ab
@void256
Member
void256 commented Mar 27, 2016

3a1a5ab should fix that issue finally.

Can somebody confirm that with a 1.4.2-SNAPSHOT build it now works better?

Starting with 1.4.2-SNAPSHOT the eventbus is included into the nifty.jar so there is no need for the eventbus-1.4.jar to be in the classpath. In fact the eventbus-1.4.jar MUST be removed from the runtime classpath to prevent any conflicts with the now included eventbus

@tonihele
tonihele commented Apr 2, 2016

Great! I didn't try it yet. I'm just wondering, that since jMonkeyEngine is getting really close pushing 3.1 version out. Nifty is still the default GUI library there (1.4.1), but a bug like this is quite off putting. Simple Hello world and your app might not shutdown... Sooooo, is there anyway you could try to sync 1.4.2 release with JME 3.1?

I'm just an user of Nifty & JME. Not in any other way affiliated with those. So sorry if I over stepped my rights.

@void256
Member
void256 commented Apr 2, 2016

No, you didn't over stepped anything ๐Ÿ˜‰

We had that discussion before and the solution was that JME ships with whatever Nifty version is current at the time of their release. Synchronisation between the projects will otherwise be very difficult and would delay everything even more.

From my current point of view this doesn't necessarily has to be a released version of Nifty - it could be a SNAPSHOT, when the following two things are obeyed:

  1. The SPI that the Nifty version in question provides is stable. This is the case for the 1.4.x branch. So there are no changes expected for the part that is implemented on the JME-side. I'm not aware of any changes planned in the Nifty SPI for 1.4.x since we started to shift our main focus a bit more to 2.0 development currently.
  2. The Nifty version in question is in itself "kinda" stable. This applies to the current 1.4.x branch as well as far as I know. Yes, it's "kinda" a development version but again, since we shift focus to 2.0 a bit there are no big changes to be expected.

So for 1.4.2 I, at least, would be fine when JME includes a 1.4.2-SNAPSHOT build.

There is always a risk that the Nifty version included has issues, released version or not.

Please note that this only applies to the current state of 1.4.x (as outlined above) and might change in the future. For instance it's probably NOT a good idea to include 2.0-SNAPSHOT any time soon ๐Ÿ˜‰ but for 1.4.2-SNAPSHOT that's ok for now.

That being said .. we should release 1.4.2 soon ๐Ÿ˜„ However, it's not planned yet and I need to talk to @bgroenks96 first, if there are some issues remaining we really should fix for 1.4.2. If not, then I don't think there is much that would prevent that. 1.4.2 is the first release that will be available in the maven central so this might delay things a bit since we first need to make sure that everything we depend on is on the central as well. I've not checked that yet iirc but that's the only thing I'm aware off that would delay the release a bit longer.

PS: It would be nice if we find someone that could actually confirm that this issue is fixed using the latest NIfty 1.4.2-SNAPSHOT build since I happen to not be able to reproduce it by myself - but I'm not using JME so it would be nice if maybe @TripleSnail could do that?
PPS: The monkeys are cool but I'm not really following them that close anymore. What's missing is someone like you, that is using and following both projects. Are you interested in becoming like Niftys JME foreign minister? ๐Ÿ˜Ž

@TripleSnail

Unfortunately replacing old nifty jars with nifty 1.4.2-SNAPSHOT jars didn't seem to solve the problem. Here's what I did. (Please tell me if I need to do something else too)

  1. Download 1.4.2-SNAPSHOT jars
  2. Remove Nifty 1.4.1 jars (nifty, nifty-default-controls, nifty-style-black)
  3. Put equivalent Nifty 1.4.2 jars in place and rename them so that they have the same names as the removed Nifty 1.4.1 jars (so that I don't need to change paths etc.)
  4. Clean & Build
  5. Launch game
  6. Close game

The process didn't terminate. Here's the thread dump:


2016-04-02 20:31:53
Full thread dump OpenJDK 64-Bit Server VM (25.72-b15 mixed mode):

"Attach Listener" #26 daemon prio=9 os_prio=0 tid=0x00007f38f4001000 nid=0x23f4 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"Timer-1" #25 prio=5 os_prio=0 tid=0x00007f38c8c7d000 nid=0x23c8 in Object.wait() [0x00007f391973c000]
   java.lang.Thread.State: TIMED_WAITING (on object monitor)
    at java.lang.Object.wait(Native Method)
    - waiting on <0x000000077336feb0> (a java.util.TaskQueue)
    at java.util.TimerThread.mainLoop(Timer.java:552)
    - locked <0x000000077336feb0> (a java.util.TaskQueue)
    at java.util.TimerThread.run(Timer.java:505)

"process reaper" #22 daemon prio=10 os_prio=0 tid=0x00007f38c802a800 nid=0x23c1 waiting on condition [0x00007f3928eac000]
   java.lang.Thread.State: TIMED_WAITING (parking)
    at sun.misc.Unsafe.park(Native Method)
    - parking to wait for  <0x00000006ca0316f0> (a java.util.concurrent.SynchronousQueue$TransferStack)
    at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
    at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:460)
    at java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:362)
    at java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:941)
    at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1066)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745)

"DestroyJavaVM" #20 prio=5 os_prio=0 tid=0x00007f395000a000 nid=0x23a6 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"AWT-XAWT" #15 daemon prio=6 os_prio=0 tid=0x00007f3950769800 nid=0x23bb runnable [0x00007f392b9ee000]
   java.lang.Thread.State: RUNNABLE
    at sun.awt.X11.XToolkit.waitForEvents(Native Method)
    at sun.awt.X11.XToolkit.run(XToolkit.java:568)
    at sun.awt.X11.XToolkit.run(XToolkit.java:532)
    at java.lang.Thread.run(Thread.java:745)

"Java2D Disposer" #13 daemon prio=10 os_prio=0 tid=0x00007f3950741000 nid=0x23ba in Object.wait() [0x00007f39301c1000]
   java.lang.Thread.State: WAITING (on object monitor)
    at java.lang.Object.wait(Native Method)
    - waiting on <0x00000006ca01f3d8> (a java.lang.ref.ReferenceQueue$Lock)
    at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:143)
    - locked <0x00000006ca01f3d8> (a java.lang.ref.ReferenceQueue$Lock)
    at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:164)
    at sun.java2d.Disposer.run(Disposer.java:148)
    at java.lang.Thread.run(Thread.java:745)

"Timer-0" #11 daemon prio=5 os_prio=0 tid=0x00007f395062e000 nid=0x23b9 in Object.wait() [0x00007f39320c3000]
   java.lang.Thread.State: TIMED_WAITING (on object monitor)
    at java.lang.Object.wait(Native Method)
    - waiting on <0x00000006ca031ac8> (a java.util.TaskQueue)
    at java.util.TimerThread.mainLoop(Timer.java:552)
    - locked <0x00000006ca031ac8> (a java.util.TaskQueue)
    at java.util.TimerThread.run(Timer.java:505)

"Service Thread" #9 daemon prio=9 os_prio=0 tid=0x00007f3950213800 nid=0x23b7 runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"C1 CompilerThread3" #8 daemon prio=9 os_prio=0 tid=0x00007f3950206800 nid=0x23b6 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"C2 CompilerThread2" #7 daemon prio=9 os_prio=0 tid=0x00007f3950202000 nid=0x23b5 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"C2 CompilerThread1" #6 daemon prio=9 os_prio=0 tid=0x00007f3950200000 nid=0x23b4 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"C2 CompilerThread0" #5 daemon prio=9 os_prio=0 tid=0x00007f39501fd000 nid=0x23b3 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"Signal Dispatcher" #4 daemon prio=9 os_prio=0 tid=0x00007f39501fb000 nid=0x23b2 runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"Finalizer" #3 daemon prio=8 os_prio=0 tid=0x00007f39501d2800 nid=0x23b1 in Object.wait() [0x00007f39330ef000]
   java.lang.Thread.State: WAITING (on object monitor)
    at java.lang.Object.wait(Native Method)
    - waiting on <0x00000006ca02cc60> (a java.lang.ref.ReferenceQueue$Lock)
    at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:143)
    - locked <0x00000006ca02cc60> (a java.lang.ref.ReferenceQueue$Lock)
    at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:164)
    at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:209)

"Reference Handler" #2 daemon prio=10 os_prio=0 tid=0x00007f39501ce000 nid=0x23b0 in Object.wait() [0x00007f39331f0000]
   java.lang.Thread.State: WAITING (on object monitor)
    at java.lang.Object.wait(Native Method)
    - waiting on <0x00000006ca02ce78> (a java.lang.ref.Reference$Lock)
    at java.lang.Object.wait(Object.java:502)
    at java.lang.ref.Reference.tryHandlePending(Reference.java:191)
    - locked <0x00000006ca02ce78> (a java.lang.ref.Reference$Lock)
    at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:153)

"VM Thread" os_prio=0 tid=0x00007f39501c6800 nid=0x23af runnable 

"GC task thread#0 (ParallelGC)" os_prio=0 tid=0x00007f395001f000 nid=0x23a7 runnable 

"GC task thread#1 (ParallelGC)" os_prio=0 tid=0x00007f3950020800 nid=0x23a8 runnable 

"GC task thread#2 (ParallelGC)" os_prio=0 tid=0x00007f3950022800 nid=0x23a9 runnable 

"GC task thread#3 (ParallelGC)" os_prio=0 tid=0x00007f3950024000 nid=0x23aa runnable 

"GC task thread#4 (ParallelGC)" os_prio=0 tid=0x00007f3950026000 nid=0x23ab runnable 

"GC task thread#5 (ParallelGC)" os_prio=0 tid=0x00007f3950027800 nid=0x23ac runnable 

"GC task thread#6 (ParallelGC)" os_prio=0 tid=0x00007f3950029800 nid=0x23ad runnable 

"GC task thread#7 (ParallelGC)" os_prio=0 tid=0x00007f395002b000 nid=0x23ae runnable 

"VM Periodic Task Thread" os_prio=0 tid=0x00007f3950216000 nid=0x23b8 waiting on condition 

JNI global references: 368

@void256
Member
void256 commented Apr 2, 2016

Thanks for testing!

Did you do that part as well:

In fact the eventbus-1.4.jar MUST be removed from the runtime classpath to prevent any conflicts with the now included eventbus

?

@bgroenks96 bgroenks96 removed the wontfix label Apr 2, 2016
@TripleSnail

No I didn't but now that I did my game doesn't compile anymore.

error: cannot access EventSubscriber
                        .getRenderer(TextRenderer.class);
  class file for org.bushe.swing.event.EventSubscriber not found

The line was like this:

TextRenderer text = rows.get(i).getRenderer(TextRenderer.class);

I'm not sure why the error happened there since there are many places where I call getRenderer with TextRenderer.class

@void256
Member
void256 commented Apr 2, 2016

That's odd! This class is now a part of the nifty.jar and should be available!

Where did you get your 1.4.2-SNAPSHOT jar from?

We've changed the repo some weeks ago. The correct place is now here:
https://oss.sonatype.org/content/repositories/snapshots/com/github/nifty-gui/nifty/1.4.2-SNAPSHOT/

And the correct version is the latest one:
https://oss.sonatype.org/content/repositories/snapshots/com/github/nifty-gui/nifty/1.4.2-SNAPSHOT/nifty-1.4.2-20160327.130755-19.jar

I've just downloaded this jar and extracted it's content. The class is there!

Can you check again if you're using the correct jar?

@TripleSnail

I created empty Maven-based project and put this in it (directly from the README.md):

<dependencies>
        <dependency>
            <groupId>com.github.nifty-gui</groupId>
            <artifactId>nifty</artifactId>
            <version>1.4.2-SNAPSHOT</version>
        </dependency>

    </dependencies>
    <repositories>
        <!-- only needed for snapshot builds starting with 1.4.2-SNAPSHOT -->
        <repository>
            <id>ossrh</id>
            <url>https://oss.sonatype.org/content/repositories/snapshots/</url>
        </repository>

        <!-- still needed for some other dependencies not yet available in central like jglfont -->
        <repository>
            <id>nifty-maven-repo.sourceforge.net</id>
            <url>http://nifty-gui.sourceforge.net/nifty-maven-repo</url>
        </repository>
    </repositories>

I compiled the project (mvn compile) so that maven would download the dependencies. I then went to ~/.m2/repository/lessvoid/nifty/1.4.2-SNAPSHOT and copied the nifty-1.4.2-SNAPSHOT.jar and replaced the previous nifty-jar with that. I did the same for the other jars (are they relevant though?).

The only other jar I saw there was nifty-1.4.2-20151105.200211-15.jar.

I just downloaded the jar (with my browser) that you linked to and used that. Now my game seems to terminate cleanly!

@tonihele
tonihele commented Apr 3, 2016

PPS: The monkeys are cool but I'm not really following them that close anymore. What's missing is someone like you, that is using and following both projects. Are you interested in becoming like Niftys JME foreign minister? ๐Ÿ˜Ž

Well, depends what is expected of me? :) I'm just struggling to get my game up and running. I'm not that literate in Nifty nor JME. But I do have a built-in paternal instinct that want everything to work nicely on both. For everybody.

@bgroenks96
Collaborator

But I do have a built-in paternal instinct that want everything to work nicely on both. For everybody.

๐Ÿ‘ You're hired ;)

@bgroenks96
Collaborator

@void256 We need to get some documentation up somewhere about this for current Nifty/JME users. Once that's done, I think we can close this issue.

@tonihele
tonihele commented Apr 3, 2016

jMonkeyEngine/jmonkeyengine#330, here is the JME issue for this.

@MeFisto94 MeFisto94 referenced this issue in jMonkeyEngine/sdk Apr 3, 2016
Open

Upgrading bundled Nifty #48

@void256
Member
void256 commented Apr 3, 2016

@TripleSnail
I've just tried the same (with removing the local maven repo) and I do get the correct "nifty-1.4.2-20160327.130755-19.jar" version. Maybe you've used that empty Maven project trick before and Maven did not update the SNAPSHOT correctly? There is the -U option to force the update of SNAPSHOT-Dependencies. I don't have any other explanation.

@tonihele
Yep, you're hired ๐Ÿ˜‰ There are no specific tasks tho. Just keep an eye on JME development and Nifty development and maybe just help to align both a bit at times. That's all, I guess.

@bgroenks96
Thanks for the excellent explanation on the related JME ticket. Well done! ๐Ÿ˜„

I'll close this issue now since the original problem appears to be solved. If necessary for us to create a new issue for the JME integration we should do that.

@void256 void256 closed this Apr 3, 2016
@TripleSnail

Yeah I was looking from the wrong directory. Should have looked at com/github/nifty-gui/nifty and not lessvoid. I hadn't used that trick before but I once compiled jME from source using Gradle which could explain how the old version got there.

Thanks for everybody involved in fixing this problem :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment