Basic Gradle template needs updating

Documentation
1

I was looking at this project:

And it is very much out of date, especially considering the imminent EOL for Java 11.

I’m happy to do an update, but what work-flow would I use?

1 Like
2

An alternative is the intialiser https://start.jmonkeyengine.org/ which will build you a starter project based on data you supply. It’s certainly more up to date (i recently changed it to java 17 for desktop projects)

1 Like
3

Which works well, except for the “-XstartOnFirstThread” issue that Macs have (or perhaps it’s only ARM64 Macs?).

But that project should either be updated or removed. I got to it from a link/reference, so people could stumble on it and have unnecessary troubles.

1 Like
4

I agree, it might be updated. (i didnt even knew it was outdated)

But also might be just removed since we have: https://start.jmonkeyengine.org/

Good catch @AceMcCloud

About the workflow, i might be wrong now, but i belive creating github issue on github and making fork with pull-request into oryginal repo added into github issue might be enough.
But here project owners should confirm.

In every case Github issue should exist to initialize “discussion to decide action” on github. (its not like they do not see it here, but there is more formal i guess)

5

Is that “-XstartOnFirstThread” issue with the initializer template?

If you want to make a PR the source for the initializer it is at GitHub - jMonkeyEngine/jme-initializer and the templates themselves are formed in https://github.com/jMonkeyEngine/jme-initializer/tree/master/src/main/resources/jmetemplate (its mostly just merge fields)

6

If the initializer templates are how “start.jmonkeyengine.org” is implemented, then yes, that’s where the issue is. The resulting project file needs one addition for Macs.

I added it to build.gradle inside an application block, but I’m sure there are at least 50 other ways to do that in Gradle.

7

jMonkeyEngine desktop APIs use LWJGL, this flag is stated by LWJGL, see more:
https://www.lwjgl.org/guide

8

Ah yes, this is coming back to me now. The template does include that in the .command file for macos so a distribution for macos made with the template ought to work. But I assume this is for a mac as a development machine.

Did you do something like this

application {
    mainClassName = 'com.example.Game'
    applicationDefaultJvmArgs = ['-XstartOnFirstThread']
}

I think on non mac OSs that would just be ignored so would probably be fine to have in the template (with a comment to explain it)

What are you running with, just command line or an IDE like intelliJ

9

I use IntelliJ IDEA.

And that’s pretty much exactly what I added to my own build.gradle file. But then, I’m not a programming newbie, even though I am new to game development.

10

Is jMonkeyEngine Templates · GitHub actually a JMonkey repository? Despite the name it all seems to be Jayfella. If that’s the case it may not be possible to update it and it’s unlikely Jayfella will respond to requests as he’s left JMonkey.

Edit; That said, @AceMcCloud where was the link that led you there? That might be removable

[It isn’t yet deployed but I’ve made some changes to the initialiser so it should include that -XstartOnFirstThread option on built templates]

1 Like
11

I don’t remember where the link was, and have not been able to find it. But If I find it again, I’ll fix it, post a comment, or contact the author (depending on where it was).

1 Like
12

@AceMcCloud the new version of the initialiser has been deployed. Do templates generated from it now work for you on mac?

3 Likes
13

That worked just fine, thank you!

3 Likes
14

That is Jmonkey’s biggest issue, so many things are not part of the engine and they are 3rd party. 3rd party comes and goes and users using JME are left not knowing which thing to use, or which library is not supported anymore. Or even worse, other people fork it and start doing things to it, then the user had no clue which one to use anymore.

To my the biggest issue with JME is not integerating nice 3rd party features into the engine. Many it doesn’t have to be compiled with the regular engine, but be part of it, so that it is always being updated by everyone and not just a stand alone that ends up behind or broken.

I so wish 3rd party things would be integrated into the engine as an official library.

2 Likes
15

I hear your concerns @kevinba99.

I disagree with your belief that making something part of the Engine means it will get updated.

In the past, code was often integrated into the Engine about the time its creator(s) lost interest in maintaining it. (I’m unsure about cause and effect here.) After that, if nobody steps up to maintain it, it languishes and rapidly becomes obsolete. I hate that.

There’ve been times in the past when the jmonkeyengine repo at GitHub was getting lots of attention. In case you haven’t noticed, that’s not the case in 2023. The master branch has received only 5 commits so far this month. We don’t have enough people working on the Engine, and I suspect the SDK and the Wiki are in the same situation.

The situation is even worse for other “official” JMonkey repos like monkeyzone, examplegame-skulls, cubes, BlenderLoader, and Jme3Bullet.

Lemur, Minie, and similar libraries get maintained because their creators are actively using them and it’s clear who’s responsible for them. They get better maintenance as 3rd-party software than they ever would if they were part of the Engine.

5 Likes
16

I agree with sgold on this. I have also lived here since 2014. And even when the development was very active, bigger releases took a year or so to materialize. That is a long time to wait for a bug to be fixed or a feature to land. Independently those libraries could move a lot faster and weren’t tied to jME’s cycle. Without jME’s bureaucracy the libraries are more agile.

The initializer / SDK does its best to let people know about their options. This I do understand that this is a bit of a burden to a first timer (I have been there too) since they would need to do some research what option is the best for them. We just need better instructions on this…

2 Likes
17

Engine update:
User identifies a problem.
User submits a patch.
User goes through the trouble to work through the review process.
User gets really excited their change makes it in.
…6 months to a year later, there change finally shows up in a release.
User has already worked around the issue in a local fork and doesn’t pay much attention to those releases anymore. We are unlikely to get another contribution from that user.

The external libraries can get a similar turn around in days or weeks. (Though I’m about 3 months behind on my own library releases… something really important would still make it in over a weekend.)

3 Likes
18

Getting back to Kevin’s main point:

We can always do more to steer users toward actively supported libraries. For example:

Other ideas?

3 Likes
19

I compiled a list of jme-related 3rd party libraries on github. I’d be happy to port it over to the official wiki.

5 Likes
20

It’s a good list. I encourage you to submit a pull request to the Wiki.

3 Likes