Video : JMonkey with gradle

General Discussion
1

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
2

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

3

great tutorial! thanks =)

4

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
5

Thank you for watching it and for the feedback.

6

By the way, what does this notation actually mean?

7

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
8

Now I understand why I couldnā€™t find it on the gradle documentation :rolling_eyes:

9

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.

10

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

11

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.

12

The same reason one uses rolling releases.

14

And for Android, what changes should i make?

15

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

16

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

This may be helpful for you.

1 Like
17

thanks for the information, really useful

18

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
19

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
20

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?

2 Likes