Video : JMonkey with gradle

I uploaded a video on how to create, build and run a JMonkey project with gradle if anyone wants to check it out

Like it if you like it :slight_smile:

15 Likes

Thanks @gbluntzer. Was very helpful for me.:heart:

great tutorial! thanks =)

Notes as I’m watching:

Single quotes versus double quotes in gradle:

Single quotes and double quotes mean different things in gradle. As I recall, single quotes means a string literal… no variable substitution. Also, I think if you used single quotes for the dependencies with the range expansion then it wouldn’t expand the range. You used var substitution in yours but some folks also do:
“org.jmonkeyengine:jme3-core” + jmeVersion
…which I’m 99% sure wouldn’t work as:
‘org.jmonkeyengine:jme3-core’ + jmeVersion
…because the [3.1,) won’t get expanded.
…that could be superstition though.

Suffice it to say that single quotes and double quotes are different. When single quotes doesn’t work for something then try double quotes. :slight_smile:

jme3 dependencies

jme3-core is the core library.
jme3-desktop is what you need to run on desktop (as opposed to mobile).

Next Steps

For most people, the next immediate step would be to have assets. Adding an assets folder that compiles to an assets.jar turns out to be pretty simple with some gradle tricks.

Gradle supports the idea of subprojects that have no actual project file. (ie: no build.gradle of their own).

To do this:

  1. Create the assets directory
  2. Open the project’s settings.gradle and add include ‘assets’
  3. Edit the project’s build.gradle file and add:
project(":assets") {
    apply plugin: "java"
    
    buildDir = rootProject.file("build/assets")
    
    sourceSets {
        main {
            resources {
                srcDir '.'
            }
        }
    }    
}

That tells gradle about the assets subproject.

Now in your project’s dependencies include:
runtime project(’:assets’)

…to include the assets.jar file as a runtime dependency.

Now if you were to package up your application then it will also include the assets.jar file.

As per another thread, a full project example can be found here with assets support:

8 Likes

Thank you for watching it and for the feedback.

By the way, what does this notation actually mean?

http://maven.apache.org/enforcer/enforcer-rules/versionRanges.html

In short, it means anything greater than or equal to 3.1… in this case, the ‘latest’ by whatever logic latest is using to determine latest. (Unfortunately, more or less just string comparison.)

1 Like

Now I understand why I couldn’t find it on the gradle documentation :rolling_eyes:

Gradle also supports 3.1.+ but then if you publish to a maven compatible repo then you screw up any maven builds that try to depend on you.

You could also use a custom pom generation in gradle, that when uploading resolves the actual version for that build, so that it stays compatible to the specifications.

eg
3.1+ is resolved to 3.1.4-alpha2 upon uploading

Maven supports version ranges… presumably if you put version ranges in your gradle file then you want to use version ranges. Else, just use a specific version in your gradle file.

I’m not sure I understand why one would want one build to behave differently than another.

The same reason one uses rolling releases.

And for Android, what changes should i make?

https://hub.jmonkeyengine.org/search?q=android%20gradle :wink:

use jme3-android instead of jme3-desktop, jme3-android-native instead of jme3-bullet-native.

This may be helpful for you.

1 Like

thanks for the information, really useful

Rather that use the subproject why not just declare the assets folder as a resources folder?

Within build.gradle:

sourceSets {
    main {
        resources {
            srcDir 'assets'
        }
    }
}

The subproject approach seems to upset some IDEs (e.g. Intelij) whereas its happy with the resources approach (And delegating to gradle for the builds is much slower than letting Intelij handle it)

1 Like

That could be the solution to my problem having to sync every now and then when intelliJ doesn’t know anything about the codebase anymore. And also I had delegate because of some problems enabled, I think

Edit: So thanks for sharing

1 Like

Note that treating the assets directory as source resources has some down sides. Your mileage may vary as to how significant those downsides are… but…

  1. code and assets will always be bundled together, even if you’d rather distribute them separately.
  2. that means that every time you update a java file, the entire ginormous jar that includes everything needs to be repackaged (versus assets only when assets change).

For projects without many assets this shouldn’t matter. Anything over 20 mb or so, I suspect it will be unpleasant in the long run.

Perhaps what’s need to make the IDEs act more intelligently is a build.gradle in the assets folder?

1 Like