Extend/improve Gradle project wizard

[peedeeboy]

trafficstars

Summary

Based on the jmeinitializer, this PR aims to add similar functionality to the JME SDK itself. In the future, the SDK could be update to call the initilizer API to get a new Gradle project (this is how the NB Spring Boot plugin works..).

The new Gradle game wizard now uses NB's built in FreeMarker template engine to replace the build.gradle and settings.gradle files from the .zip with templated versions depending on what the user selects.

Templating the settings.gradle means the Project will display with the correct name in NB's Project Window.

New wizard workflow

Example build.gradle

plugins {
    id 'java'
    id 'application'
}

group 'com.mygame'
version '1.0'

mainClassName = "com.mygame.Main"

repositories {
    mavenCentral()
    jcenter()
    maven { url 'https://jitpack.io' }
}

project.ext {
  jmeVer = '3.5.0-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.15.0"
  
  // Physics Library
  implementation "com.github.stephengold:Minie:4.4.0"
  
  // Networking Library
  implementation "org.jmonkeyengine:jme3-networking:$jmeVer"

  // Additional Libraries
  implementation "org.jmonkeyengine:jme3-effects:$jmeVer"
  implementation "org.jmonkeyengine:jme3-terrain:$jmeVer"
  implementation "com.github.stephengold:Heart:7.2.0"
  implementation "com.simsilica:zay-es:1.3.2"

  // Assets sub-project
  runtimeOnly project(':assets')
}

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

TODO

This could be further expanded to user NB's built-in Gradle wrapper class to run gradle init, this would allow the user to set the Group etc. and would allow create of sub-projects for different build targets (iOS, Android etc.). I don't know enough about jMonkey build targets outside of Linux/Windows desktop yet though, so decided to submit this PR as-is for now...

[peedeeboy]

Drop down options are represented by Enums. Adding a new option is as simple as:

1. Add a new Enum entry
2. Add the description into bundle.properties
3. (For JME Version only) create the patch notes .html file

[neph1]

Looks interesting! Does this solve any of the issues with the current template, as well? Would you consider looking through the analysis issues? It seems a lot of them could be solved by simply running the auto-formatter.

[MeFisto94]

Very awesome :)

Without having looked at the code, yet:

and would allow create of sub-projects for different build targets (iOS, Android etc.). This is something we want to go for, see #302 . That will also replace the current template.

Speaking of the example build.gradle file: We need to remove jcenter() as that is taken offline. Besides that, a small change to the formatting of the additional libraries: jMonkeyEngine Virtual Reality (jme3-vr) (capitalization and not losing the 3 🙂)

I'll have a look at the code and test the feature soon! thanks!

[MeFisto94]

The code is looking good 😄 . Did you have prior experience with Netbeans or did you just learn that by doing? I am not sure what happens to codacy, at least the inline comments seem to be odd sometimes and also not sure if we can filter/prevent it from analyzing generated code, besides that it may have some valid findings here and there.

[peedeeboy]

@MeFisto94 thank you for your kind words and feedback:

We need to remove jcenter() as that is taken offline.

The most recent thing I saw was this jFrog update saying jCenter was going to be kept read-only indefinitely now? Is it ok to leave it in? I wanted to be able to offer @pspeed42 's Zay-ES etc as recommended 3rd party libraries and jCenter seems better to use than JitPack if possible...

Besides that, a small change to the formatting of the additional libraries

Will find some time to fix this week/weekend :+1: Do you prefer me to push an additional commit (so you can easily see the changes), or to squash + force push so it is ready to merge?

Did you have prior experience with Netbeans or did you just learn that by doing?

I've submitted a handful (of admittedly fairly straightforward) PRs to the main NB project :+1:

@neph1 Thanks for taking a look!!:

Does this solve any of the issues with the current template, as well?

The assets project should work nicely, which was my initial inspiration (although @MeFisto94 fixed that in the existing template whilst I was working on this). The project and asset projects will display properly in the SDK now, as NB picks them up from the settings.gradle and this PR will template that with the correct project name.

A part 2 to this PR should be to create build targets for Desktop / Android / iOS, and initialise the Gradle project using NB's gradle wrapper class (to do a gradle init) and create sub-projects. I've only tinkered with JME on desktop, so don't know enough about what the ideal multi-target project structure should look like, but if someone can provide instructions, I'd be happy to take a look....

Would you consider looking through the analysis issues? It seems a lot of them could be solved by simply running the auto-formatter.

I think most of them are caused by using the NB Matisse GUI builder, and the static analysis hates the code it produces. But as @MeFisto94 says, there are probably also some legit problems in there. I'll sift through this week/weekend and tidy up where needed :+1:

[MeFisto94]

The most recent thing I saw was this jFrog update saying jCenter was going to be kept read-only indefinitely now?

Then that's okay, still not really awesome, but if paul hasn't migrated yet, that probably means we should keep it for ease of access, as you say.

Do you prefer me to push an additional commit (so you can easily see the changes), or to squash + force push so it is ready to merge?

Just do an additional commit. I mean in this case only the final form matters and not the intermediary changes, but github can easily squash merge for us anyway.

but if someone can provide instructions, I'd be happy to take a look....

I think this should be an engine discussion, or rather: already is. I think I created an issue once and there may even be pending PRs with other suggestions

[peedeeboy]

@MeFisto94 I've added some additional commits:

• Changing what seemed sensible in the Codacy report (a lot of the errors were indeed from the auto-generate NB UI code)
• Fixed the typos you requested fixing + hid the unused title bar of the Additional Libraries jTable (looks much better)
• Added JME 3.5.1 to the list of engine options, now it is available

Hopefully, that is enough for now? As I said, if there is a community consensus on what an ideal multi-target project structure should look like, I'll happily come back and redo parts of this :)

[peedeeboy]

I also realised I made a mistake with the .zip file, so that is fixed now too

[tonihele]

Then that's okay, still not really awesome, but if paul hasn't migrated yet, that probably means we should keep it for ease of access, as you say.

Paul has migrated :)

[tonihele]

Nice work! Assets do work, that is confirmed. I think all around solid work :) I hope it is not too daunting for the first time user, so many mystical selections.

The template gives only one warning:

That is the topic you also discussed. But I think this is definitely a good start! I'll leave this to @MeFisto94

[MeFisto94]

While jCenter may now be replaced by paul, we'll probably defer that to the new multi-target project structure at some point, so it's good to go.

This is because older versions still are on jCenter then, I guess. We just need to ensure to also push engine side multi target gradle templates at some point, otherwise this will be gone and at some point in the future, when everyone wants the latest paul libraries, they always need to fix up things.

Actually: Does the template seamlessly allow you to use pauls more recent libraries? I guess since the artifactId stays the same, it should "just" work?

[peedeeboy]

Actually: Does the template seamlessly allow you to use pauls more recent libraries? I guess since the artifactId stays the same, it should "just" work?

@MeFisto94 - yes, just need to change the version number in the build.gradle and the new Gradle will pick up the new version from Maven Central, rather than the old version from JCenter

Saying that, I've updated the enums with the latest version of JME (3.5.2-stable), all of Paul's libraries and Stephen's libraries..

[tonihele]

@peedeeboy sorry about the hassle. Could you resolve the conflicts and lets then merge this?

[peedeeboy]

@tonihele - squashed, rebased and tested on 3.4.1 SDK :+1:

[tonihele]

Nice work, I'll run it through first thing tomorrow!