[Solved] Migrating standard SDK project to Gradle Template

@yaRnMcDonuts

sorry, i didnt look properly, but i also had this in project with “libs” folder separatly.

compile fileTree(dir: 'libs', include: ['*.jar'])
1 Like

By the way, I believe you can make the assets jar yourself (with 7zip) and put it beside other jars it should work :slightly_smiling_face:

Edit:
Just make sure you have added it to the classpath.

1 Like

You can freely change this. I recommend the latest of 6 series. 7 series is so new that it lacks proper IDE support. The easiest is to use the wrapper task to setup the versions.

2 Likes

In the long run, a single > 4gb jar is going to be hard to manage and you will probably want to split it into separate asset jars. It will take less time to build for just one change, etc… and if you ever use some dynamic updater tool like getdown it will make it easier to update some assets and not others without making the user download one giant jar file.

Just something to consider.

3 Likes

i agree with Paul.

Even if i told you about it, if im not wrong user would need to have 7zip/etc to open that Jar(idk if java support 7z itself) i belive? (here im curious myself)

also it would be easier to download multiple smaller jars.

And for development you already use “non-compile” runtime code so you no need wait.

1 Like

That would be very helpful to have it compile faster, since the build time can take even longer if I run anything else on my computer at the same time, and usually I do if I’m just waiting for a build to finish. So I guess I should look into doing it this way rather than trying to figure out the zip64 thing with gradle.

Since my game will be listed on Steam, I’m not sure if I’ll have much control over this since their Steam client handles the updating for players. From what I’ve noticed, it takes a pretty long time to download an update for my game on Steam even if I’ve only made a minor change to the code and don’t change the assets at all.

However, the process of uploading my game to Steam goes way faster if I’ve made less changes since the last upload, first it scans the project then appears to only upload the changes, and can take less than a minute. But downloading the update on steam as a player takes longer for some reason.

is this by any chance because you got one big JAR there? if im not wrong Steam verify “files”, so if there is JAR inside i belive it sadly consider it as single file, so any small changes within it will make client re-download all JAR

The assets are all one big jar, and then the executable code file is a separate jar.

So I would expect a small change to the assets folder to require a full update of that jar, but wouldn’t expect a change to just the executable to require the assets jar to be updated.

But this is from when I was using ant, which would also re-build the entire assets folder even if there were no changes. So technically it was a different assets jar even though I didn’t change the assets. I’ll have to see if things go any faster with the Steam update after changing only the code now that I’ll be compiling the assets jar separately.

1 Like

So I would expect a small change to the assets folder to require a full update of that jar, but wouldn’t expect a change to just the executable to require the assets jar to be updated.

That is interesting.
There are many games where “small changes” require to re-download almost all games.

But there are also games where “small changes” download 0.1% of game weight only.

So it would be worth to investigate why this happen.

1 Like

So I am once again getting an error about an invalid dependency (like I did for Lemur and Minie) even though I’m fairly certain it is correct. In which case it will hopefully go away soon and work for no apparent reason like those did, but I can’t help but wonder why this is happening?

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':compileJava'.
> Could not resolve all files for configuration ':compileClasspath'.
   > Could not find org.jmonkeyengine:jme3-testdata:3.3.0-stable.
     Searched in the following locations:
       - file:/C:/Users/ryan/.m2/repository/org/jmonkeyengine/jme3-testdata/3.3.0-stable/jme3-testdata-3.3.0-stable.pom
       - https://repo.maven.apache.org/maven2/org/jmonkeyengine/jme3-testdata/3.3.0-stable/jme3-testdata-3.3.0-stable.pom
       - https://jcenter.bintray.com/org/jmonkeyengine/jme3-testdata/3.3.0-stable/jme3-testdata-3.3.0-stable.pom
       - https://oss.sonatype.org/content/repositories/snapshots/org/jmonkeyengine/jme3-testdata/3.3.0-stable/jme3-testdata-3.3.0-stable.pom
       - https://oss.sonatype.org/content/repositories/releases/org/jmonkeyengine/jme3-testdata/3.3.0-stable/jme3-testdata-3.3.0-stable.pom
       - https://jitpack.io/org/jmonkeyengine/jme3-testdata/3.3.0-stable/jme3-testdata-3.3.0-stable.pom
     Required by:
         project :

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.

* Get more help at https://help.gradle.org

This time it’s happening with the test-data import that I forgot to include, as really old parts of my project still use it.

And here you can see it appears that I’m referncing it correctly, and am doing so very similar to the rest of my jme imports that work:

implementation "org.jmonkeyengine:jme3-testdata:$jmeVer"
implementation "org.jmonkeyengine:jme3-plugins:$jmeVer"  
implementation "org.jmonkeyengine:jme3-core:$jmeVer"

I’ve had the same thing happen with the plugins and terrain library as well, where it consistently said it cannot find them for like 20 minutes, then eventually just worked… (i’m also still confused how I got zip64 working for a single build, then it didn’t work even after changing nothing)

Is this just standard for gradle to be inconsistent like this when working with an IDE? Or can I fix this or am I doing something wrong to cause it? Because this inconsistency is making it extremely hard to get a hold on what I’m even doing right / wrong

It shouldn’t be inconsistent at all. Sites may be down for one reason or another but even then, I’d expect different errors.

You didn’t post your other dependency errors (that I saw) so I can’t really comment on those. And I’m not familiar with jme test data and didn’t even know it was pushed to a maven repo at all (it might have been, I just don’t know) since I never use it.

They were the same errors as this one, but instead of saying “jmetestdata cant be found” they just said the other libraries couldn’t be found.

I’ve never had issues like this when I built other’s projects and my own smaller projects with gradle in a command prompt, but it seems like the way gradle is working with the SDK is making it feel a lot less reliable so far.

I thought that could be the issue but when I did a bit of searching I found this thread and tried basing my attempts off of this.

Other packages same issue?

Maybe repos are down for some reason? (im using alias Nexus server so i never know)

do basic Gradle template from start page work? jMonkeyEngine | Quick Start

about testdata its hard topic, since it should not exist as repo artifact.

1 Like

I remember I was also facing issues with Gradle in Netbeans back then before I decided to switch to IntelliJ. Though, this was about a few years ago when Netbeans 11 was newly released.

1 Like
> Could not find org.jmonkeyengine:jme3-testdata:3.3.0-stable.
     Searched in the following locations:
       - file:/C:/Users/ryan/.m2/repository/org/jmonkeyengine/jme3-testdata/3.3.0-stable/jme3-testdata-3.3.0-stable.pom
       - https://repo.maven.apache.org/maven2/org/jmonkeyengine/jme3-testdata/3.3.0-stable/jme3-testdata-3.3.0-stable.pom
       - https://jcenter.bintray.com/org/jmonkeyengine/jme3-testdata/3.3.0-stable/jme3-testdata-3.3.0-stable.pom
       - https://oss.sonatype.org/content/repositories/snapshots/org/jmonkeyengine/jme3-testdata/3.3.0-stable/jme3-testdata-3.3.0-stable.pom
       - https://oss.sonatype.org/content/repositories/releases/org/jmonkeyengine/jme3-testdata/3.3.0-stable/jme3-testdata-3.3.0-stable.pom
       - https://jitpack.io/org/jmonkeyengine/jme3-testdata/3.3.0-stable/jme3-testdata-3.3.0-stable.pom

My guess would be that your build scripts are depending on some unreliable/deprecated repository such as JCenter. The best source for “jme3-testdata” would be Maven Central, which isn’t included in your repositories. Maven Central doesn’t include the “3.3.0-stable” testdata, but it does include “3.1.0-stable” and “3.4.0-stable”. Depending on what you need it for, one of those should probably work.

1 Like

Switching the version of test data to 3.4 worked, thanks!

I think I might consider switching to IntelliJ eventually as well then, if the buginess gets to be too much to work with. Thankfully the situation with the test data was just a mistake on my end, and I wrongly attributed it to the similar issue I got with the lemur and minie imports, although I still am not sure what I did (if anything) to get those to work.

The next dependency I’m having similar trouble with is for simarboreal and simFX. I referenced thee from the simarboreal editor project (since it has both dependencies I need as well)

and this is the code I am trying to use, and the error message as well:

repositories {
    mavenLocal()
    mavenCentral()
    jcenter()
    maven { url "https://oss.sonatype.org/content/repositories/snapshots/" }
    maven { url "https://oss.sonatype.org/content/repositories/releases/" }
    maven { url "https://jitpack.io" }
}
    implementation "com.simsilica:sim-arboreal:1.0.1-SNAPSHOT"
    runTime "com.simsilica:sim-arboreal:1.0.1-SNAPSHOT:assets"
    
    compile "com.simsilica:sim-fx:1.0.+"
    runtime "com.simsilica:sim-fx:1.0.+:assets"

I also tried replacing “runtime” and “compile” with “implementation” since this is what I (incorrectly) thought fixed my imports for Minie and Lemur, but it seems like either key word works for those dependencies now that they aren’t being buggy, so that must not have just been what fixed it.

> Task :compileJava FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':compileJava'.
> Could not resolve all files for configuration ':compileClasspath'.
   > Could not find com.simsilica:sim-arboreal:1.0.1-SNAPSHOT.
     Searched in the following locations:
       - file:/C:/Users/ryan/.m2/repository/com/simsilica/sim-arboreal/1.0.1-SNAPSHOT/maven-metadata.xml
       - file:/C:/Users/ryan/.m2/repository/com/simsilica/sim-arboreal/1.0.1-SNAPSHOT/sim-arboreal-1.0.1-SNAPSHOT.pom
       - https://repo.maven.apache.org/maven2/com/simsilica/sim-arboreal/1.0.1-SNAPSHOT/maven-metadata.xml
       - https://repo.maven.apache.org/maven2/com/simsilica/sim-arboreal/1.0.1-SNAPSHOT/sim-arboreal-1.0.1-SNAPSHOT.pom
       - https://jcenter.bintray.com/com/simsilica/sim-arboreal/1.0.1-SNAPSHOT/maven-metadata.xml
       - https://jcenter.bintray.com/com/simsilica/sim-arboreal/1.0.1-SNAPSHOT/sim-arboreal-1.0.1-SNAPSHOT.pom
       - https://oss.sonatype.org/content/repositories/snapshots/com/simsilica/sim-arboreal/1.0.1-SNAPSHOT/maven-metadata.xml
       - https://oss.sonatype.org/content/repositories/snapshots/com/simsilica/sim-arboreal/1.0.1-SNAPSHOT/sim-arboreal-1.0.1-SNAPSHOT.pom
       - https://oss.sonatype.org/content/repositories/releases/com/simsilica/sim-arboreal/1.0.1-SNAPSHOT/maven-metadata.xml
       - https://oss.sonatype.org/content/repositories/releases/com/simsilica/sim-arboreal/1.0.1-SNAPSHOT/sim-arboreal-1.0.1-SNAPSHOT.pom
       - https://jitpack.io/com/simsilica/sim-arboreal/1.0.1-SNAPSHOT/maven-metadata.xml
       - https://jitpack.io/com/simsilica/sim-arboreal/1.0.1-SNAPSHOT/sim-arboreal-1.0.1-SNAPSHOT.pom
     Required by:
         project :
> Could not find any matches for com.simsilica:sim-fx:1.0.+ as no versions of com.simsilica:sim-fx are available.
     Searched in the following locations:
       - file:/C:/Users/ryan/.m2/repository/com/simsilica/sim-fx/
       - https://repo.maven.apache.org/maven2/com/simsilica/sim-fx/maven-metadata.xml
       - https://jcenter.bintray.com/com/simsilica/sim-fx/maven-metadata.xml
       - https://oss.sonatype.org/content/repositories/snapshots/com/simsilica/sim-fx/maven-metadata.xml
       - https://oss.sonatype.org/content/repositories/releases/com/simsilica/sim-fx/maven-metadata.xml
       - https://jitpack.io/com/simsilica/sim-fx/maven-metadata.xml
     Required by:
         project :

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.

* Get more help at https://help.gradle.org

Next I will be trying to resolve the dependencies and will be seraching for the gradle implementation links for Wes and SkyControl, as these are the last two I will need before I can finally run my project normally again.

Edit: here is also my full gradle build file currently, I removed the assets project for now since zip64 wasn’t working out.


plugins {
    id 'java'
    id 'application'
}

group 'com.theafflictedforests'
version '1.0'

sourceCompatibility = 1.8
mainClassName = "com.theafflictedforests.MainSA.Main"

repositories {
    mavenLocal()
    mavenCentral()
    jcenter()
    maven { url "https://oss.sonatype.org/content/repositories/snapshots/" }
    maven { url "https://oss.sonatype.org/content/repositories/releases/" }
    maven { url "https://jitpack.io" }
}
 

project.ext {
  jmeVer = '3.3.0-stable' 
}

 
dependencies {

    runtime files("assets")
    
    
    implementation "org.jmonkeyengine:jme3-plugins:$jmeVer"  
    implementation "org.jmonkeyengine:jme3-core:$jmeVer"
    implementation "org.jmonkeyengine:jme3-desktop:$jmeVer"
    implementation "org.jmonkeyengine:jme3-lwjgl:$jmeVer"
    implementation "org.jmonkeyengine:jme3-effects:$jmeVer"
    implementation "org.jmonkeyengine:jme3-networking:$jmeVer"
    implementation "org.jmonkeyengine:jme3-lwjgl3:$jmeVer"
    implementation "org.jmonkeyengine:jme3-niftygui:$jmeVer" 
    implementation "org.jmonkeyengine:jme3-terrain:$jmeVer" 
    
    implementation "org.jmonkeyengine:jme3-testdata:3.4.0-stable"
    
    implementation "com.github.stephengold:Minie:4.6.1"
  
    implementation "com.simsilica:lemur:1.13.0"
    implementation "com.simsilica:lemur-proto:1.11.0"

    implementation "com.google.guava:guava:31.0.1-jre"
    implementation "org.codehaus.groovy:groovy-all:2.4.12"
    implementation "org.slf4j:slf4j-api:1.7.25"
    
    implementation "com.googlecode.json-simple:json-simple:1.1.1"
    
    implementation "com.code-disaster.steamworks4j:steamworks4j:1.8.0"
    implementation "com.code-disaster.steamworks4j:steamworks4j-server:1.8.0"

    implementation "com.simsilica:sim-arboreal:1.0.1-SNAPSHOT"
    implementation "com.simsilica:sim-arboreal:1.0.1-SNAPSHOT:assets"
    
    implementation "com.simsilica:sim-fx:1.0.+"
    implementation "com.simsilica:sim-fx:1.0.+:assets"
 
}


jar {    
    
    manifest {
        attributes 'Main-Class': "$mainClassName"
        
    }
}

I’ve also just noticed another warning message that I have been getting:

Deprecated Gradle features were used in this build, making it incompatible with Gradle 7.0.
Use '--warning-mode all' to show the individual deprecation warnings.
See https://docs.gradle.org/6.3/userguide/command_line_interface.html#sec:command_line_warning

I think the SDK auto-updated my gradle version to 7.0 when I was setting up the project, could this be an issue?

I’m not sure SimArboreal (and probably SimFX) were ever pushed to a maven repo. You may have to “gradle install” them from a checkout. Not sure, though.

2 Likes

How do I do this? Is this the same as just downloading the repo, building the jar and including that in a folder of jars? (that’s what I used to do when using Ant, so I do have the jars for both dependencies on my desktop already)

Or do you mean something else?

gradle install is a task provided by the gradle maven plugin. It’s a command that you run in the <SimArboreal/or whatever> source directory to push a maven bundle to your local artifact cache so that other projects can use it as if it had been uploaded to one of the public repositories.

2 Likes

Gradle 7 always gives this warning when invoked by the JME SDK, because the SDK uses the deprecated “-c” option. It’s a harmless warning, in my opinion.

Of course, your build scripts might also use deprecated features. Best way to find out for sure would be to invoke ./gradlew build --warning-mode all from the command line, like the diagnostic suggests.

1 Like