Decide what to do with jme3-awt-dialogs

[tonihele]

Decide what to do with jme3-awt-dialogs. Should we include it by default to a new Gradle project? Without this dependency the resolution dialog does not show. Basically it comes down to these options:

• Include it
• Don't include it
• Only include if LWJGL 2 is selected (since here it doesn't cause any problems)

Our new Gradle wizard is cool and all. We just need to make it aware that jME 3.6 and up would have this. This is slightly related to https://github.com/jMonkeyEngine/sdk/issues/371. As with that, we also have access to Maven. So we could make the check so that if it is available for this and this version, mark it (and include it).

[peedeeboy]

A quick fix is to add a numerical versions (Major = 3, Minor = 5, Patch = 0) to the JMEVersion enum, and then add a conditional check that JME major version >= 3 and minor >= 6 (and/or LWJGL version = 2) in the build.gradle.ftl FreeMarker template and add in the dependency on jme3-awt-dialogs

I was going to update the enums with latest versions when JME3.6 was released, so can smash this out super quick :+1:

TBH, I currently avoid Maven like the plague in NB, due to the issue @neph1 describes in #451 - if you enable Maven support, NB will download and unpack the entire Maven central index to your user cache, and use that for searching. This can take several minutes, and I think is a frustrating experience for new users just trying to create a project? If NB is ever updated to just search Maven repos online, I would feel much better about this option.

Another long term option is to combine forces with the jMonkey Initilizer and call the Initilizer API from the new project wizard? I think this is how the Spring Boot NB plugin works with the Spring Boot Initializer.

The downside to the initializer is it doesn't currently create an /assets folder which the ProjectAssetManager in the SDK expects - but the SDK could probably be updated to create the Assets node off the resources folder and listen there for new assets to make available e.g. in texture browser immediately.

Also. the Initializer structure of having a core app module, then different 'launcher' modules for Windows, Linux, Android etc. is probably very sensible for 'serious' JME projects, but maybe a bit complex for new users just trying to get started??

Anyways, whatever the long term solution is, I'm happy to contribute :+1:

[tonihele]

Ive already started with https://github.com/jMonkeyEngine/sdk/issues/371. The branch should be linked on the issue. I used the Maven Search API as I didnt find a way to utilize any internal NB platform functionality. Do you know anything about this?

I also will change a bit how the versions and libraries are coded. Or already changed rather. Didnt get to jME versions yet though.

On Sat, 28 Jan 2023, 12:26 Pete Whelpton, @.***> wrote:

A quick fix is to add a numerical version (3.5, 3.51, 3.52, 3.6 etc) to the JMEVersion https://github.com/jMonkeyEngine/sdk/blob/master/jme3-templates/src/com/jme3/gde/templates/gradledesktop/options/JMEVersion.java enum, and then add a conditional check that JME version >= 3.6 (and/or LWJGL version = 2) in the build.gradle.ftl https://github.com/jMonkeyEngine/sdk/blob/master/jme3-templates/src/com/jme3/gde/templates/files/freemarker/build.gradle.ftl FreeMarker template and add in the dependency on jme3-awt-dialogs

I was going to update the enums with latest versions when JME3.6 was released, so can smash this out super quick 👍

TBH, I currently avoid Maven like the plague in NB, due to the issue @neph1 https://github.com/neph1 describes in #451 https://github.com/jMonkeyEngine/sdk/issues/451 - if you enable Maven support, NB will download and unpack the entire Maven central index to your user cache, and use that for searching. This can take several minutes, and I think is a frustrating experience for new users just trying to create a project? If NB is ever updated to just search Maven repos online, I would feel much better about this option.

Another long term option is to combine forces with the jMonkey Initilizer https://start.jmonkeyengine.org/ and call the Initilizer API from the new project wizard? I think this is how the Spring Boot NB plugin works with the Spring Boot Initializer.

The downside to the initializer is it doesn't currently create an /assets folder which the ProjectAssetManager in the SDK expects - but the SDK could probably be updated to create the Assets node off the resources folder and listen there for new assets to make available e.g. in texture browser immediately.

Also. the Initializer structure of having a core app module, then different 'launcher' modules for Windows, Linux, Android etc. is probably very sensible for 'serious' JME projects, but maybe a bit complex for new users just trying to get started??

Anyways, whatever the long term solution is, I'm happy to contribute 👍

— Reply to this email directly, view it on GitHub https://github.com/jMonkeyEngine/sdk/issues/460#issuecomment-1407368301, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB7VJPQHOPCCIPB5Q4TSTSLWUTX6DANCNFSM6AAAAAAUH6ZX7Q . You are receiving this because you authored the thread.Message ID: @.***>

[peedeeboy]

You are right, it looks like the Maven Search module in core NB isn't exposed publicly 😞

I'll leave it with you, then 😉

[tonihele]

Oh and Ant projects too. Gradle was too close to the heart now.

[tonihele]

A quick fix is to add a numerical versions (Major = 3, Minor = 5, Patch = 0) to the JMEVersion enum, and then add a conditional check that JME major version >= 3 and minor >= 6 (and/or LWJGL version = 2) in the build.gradle.ftl FreeMarker template and add in the dependency on jme3-awt-dialogs

I was going to update the enums with latest versions when JME3.6 was released, so can smash this out super quick 👍

TBH, I currently avoid Maven like the plague in NB, due to the issue @neph1 describes in #451 - if you enable Maven support, NB will download and unpack the entire Maven central index to your user cache, and use that for searching. This can take several minutes, and I think is a frustrating experience for new users just trying to create a project? If NB is ever updated to just search Maven repos online, I would feel much better about this option.

Another long term option is to combine forces with the jMonkey Initilizer and call the Initilizer API from the new project wizard? I think this is how the Spring Boot NB plugin works with the Spring Boot Initializer.

The downside to the initializer is it doesn't currently create an /assets folder which the ProjectAssetManager in the SDK expects - but the SDK could probably be updated to create the Assets node off the resources folder and listen there for new assets to make available e.g. in texture browser immediately.

Also. the Initializer structure of having a core app module, then different 'launcher' modules for Windows, Linux, Android etc. is probably very sensible for 'serious' JME projects, but maybe a bit complex for new users just trying to get started??

Anyways, whatever the long term solution is, I'm happy to contribute 👍

@peedeeboy I have merged the Maven API automation things. And there I changed how the versions are interpreted. They can be now quite accurately be compared. And the enums can still be manually updated. Manually entered enums always override the automation. Which may or may not work always :)

[tonihele]

Lets include jme3-awt-dialogs to all projects (Ant & Gradle, with Ant need to check that they are also in the test projects etc). It can be manually stripped of by users. But it is mighty handy in the beginning of a journey. This was also the consensus at the forums...