Gradle: Jeddic:particlemonkey:1.0.2 leads to JME 3.7.0-beta1.2.2

Hello everyone, I think I found a bug or maybe for me something very confusing. I set up a gradle project using the jMonkey-SDK 3.5.2. In the build.gradle I put the JME-Version to jmeVer = ‘3.5.2-stable’. But when I add the implementation "implementation “com.github.Jeddic:particlemonkey:1.0.2"” to the build.gradle, then my JME-Version changes automatically to “jMonkeyEngine 3.7.0-beta1.2.2”: I don’t mean, that it changes in the build.gradle. There was all the time the ‘3.5.2-stable’ in my build.gradle. But when I run a SimpleApplication, then I could see, that the JME-Version had changed.

I printed it out programatically by using System.out.println(JmeVersion.FULL_NAME) and could also see it as version in the title of the application-window.

When I don’t use these implementation in my build.gradle, then my JME-Version is as expected: “jMonkeyEngine 3.5.2-stable”.

This seems a little bit confusing, because I had some errors and could not find the reason, until I found out, that I was using JME 3.7-beta without knowing.

My build.gradle:

plugins {
id ‘java’
id ‘application’
}

group ‘com.neolithicrevolution’
version ‘1.0’

mainClassName = “com.neolithicrevolution.main.Main”

repositories {
mavenCentral()
maven { url ‘https://jitpack.io’ }
}

project.ext {
jmeVer = ‘3.5.2-stable’
}

project(“:assets”) {
apply plugin: “java”

buildDir = rootProject.file("build/assets")

sourceSets {
    main {
        resources {
            srcDir '.'
        }
    }
}

}

dependencies {

// Core JME
implementation “org.jmonkeyengine:jme3-core:$jmeVer”
implementation “org.jmonkeyengine:jme3-desktop:$jmeVer”
implementation “org.jmonkeyengine:jme3-lwjgl3:$jmeVer”

// Suppress errors / warnings building in SDK
implementation “org.jmonkeyengine:jme3-jogg:$jmeVer”
implementation “org.jmonkeyengine:jme3-plugins:$jmeVer”

// GUI Library
implementation “com.simsilica:lemur:1.16.0”
implementation “com.simsilica:lemur-proto:1.13.0”
implementation “com.simsilica:lemur-props:1.2.0”

// Physics Library
implementation “org.jmonkeyengine:jme3-jbullet:$jmeVer”

// Additional Libraries
implementation “org.jmonkeyengine:jme3-effects:$jmeVer”
implementation “org.jmonkeyengine:jme3-terrain:$jmeVer”
implementation “org.jmonkeyengine:jme3-testdata:$jmeVer”
implementation “org.jmonkeyengine:jme3-vr:$jmeVer”
implementation “com.github.stephengold:Heart:8.1.0”
implementation “com.github.Jeddic:particlemonkey:1.0.2”
implementation “com.simsilica:sio2:1.7.0”
implementation “com.simsilica:zay-es:1.4.0”
implementation “com.simsilica:zay-es-net:1.5.0”

// JAXB
implementation “com.sun.xml.bind:jaxb-impl:2.3.3”

// Assets sub-project
runtimeOnly project(‘:assets’)
}

jar {
manifest {
attributes ‘Main-Class’: “$mainClassName”
}
}

When you depend on a project that depends on a newer version of JME then transitively your project will depend on that newer version of JME. That’s the way versioning works.

Otherwise, you could depend on “fancy new thing” but “fancy new thing” depends on features that are not on “old crusty JME” and then things break obviously or randomly.

That’s the best place to start. JME 3.5 is quite old at this point.

Thank you. It is understandable, that in this case the JME-version changes. It feels a little bit confusing, that the change of the JMW-version happens in the background transitively. But I think I have to give a more precise look to my implemented libraries, and not just implement them headless.

Is it really recommended, to use the 3.7.-beta at the moment (because of the “beta”)?

It feels a little bit confusing, that the change of the JMW-version happens in the background transitively

It is one of those situations where there isn’t really any right answer. Because JME feels more like a framework it feels particularly odd but imagine a more minor (but still well used) library like Apache Commons. Imagine you use two libraries Foo-vehicles and Bar-effects. Foo wants Apache Commons 1.2 and Bar-effects wants Apache Commons 1.3. Gradle tries to satisfy everyones dependencies but there is a conflict so it can’t make everyone happy. It has a number of ResolutionStrategys it can use for dependency resolution.

By default gradle will use the highest version of any of the dependencies; this is usually an ok option, things are usually backwards compatible. It is probably the only option that really has a hope of working.

You can override the resolution stratergy though, e.g. failOnVersionConflict in this case it will just refuse to build and make you decide (maybe that is what you want?)

That version of particlemonkey seems to have said that it absolutely must have jMonkeyEngine 3.7.0-beta1.2.2. That feels a little surprising to me and I looked at it’s source build.gradle and it seems to only want 3.2. So I think there might be more going on here. Might be worth using the gradle command dependencies to get the dependency tree

Is it really recommended, to use the 3.7.-beta at the moment (because of the “beta”)?

Do you plan on releasing in the next couple of months. If so probably not, but if not you might as well (and upgrade to 3.7 proper before release). Running (in development) helps with the testing of the new version

1 Like

Thank you. These informations are very helpful. The dependency tree seems to be very nice. At the moment I don’t use the particlemonkey-library, so I just put it out of my build.gradle.

At the moment I don’t have a plan of when I will release my project (I just came back to this project after more than a year without working on it). I will give a closer look to the 3.7-beta.

Version 1.1.0 is the current one I have published for particle money and as far as I’m aware it was on 3.3.2-stable.

Looking at gradle dependencies will tell you where it pulled in the newer version of JME. Everything that it upgraded for you (because of that other dependency) will have a star next to it or something.

Yes. It’s safe to use 3.7 beta. There’s only one issue with texturing that prevented it from moving to stable state. @sgold is helping me to find that issue and hopefully soon (very soon) we will have a stable version

6 Likes