and replace jme3-jbullet with Minie, (far from likely at this point!) I believe all that would only impact about 5% of jme3-examples.
What scares me about these ideas is how much Wiki updating would be required to properly support them.
It wouldn’t be gone, just rolled into a separate library I guess like the other stuff.
I assume that if we rolled jme3-vr and/or jme3-nifty into separate projects, nobody would maintain and release them. That’s what’s happened with jme3-blender and jme3-bullet/jme3-bullet-natives since they were rolled into Jme3Bullet and BlenderLoader.
We should provide a few sample gradle files that manages the reccommended components (and point out the “deprecated” status of LWGL2/nifty etc). I don’t see a valid reason to snapshot a library; most users will just want to grab the latest of everything anyway…
Wiki and examples should be marked as deprecated as well, and eventually hopefully be updated.
Could be that some are just obsolete. Blender and Bullet. The small minority still using them need to either start learning how to maintain these (yikes…) or migrate to more up-to-date solutions. I totally understand the need for these actions. Just a heavy burden to carry. I already see myself maintaining the jme3-nifty library Hopefully it doesn’t need much as the Nifty itself probably doesn’t get any new releases and maybe jME has a pretty stable API at this time…
I agree with @Pesegato that snapshots wouldn’t be the way to go. Maybe even no need to include. Just instructions, “want UI? get x”. SDK can be used to create build file with wanted dependencies. Even the web side could bake this build file (or just the dependencies in Gradle/Maven format) for experienced users to jump start their jME project in their favourite IDE.
Just want to remind you, that there is some people with less experience.
I remember that one fellow monkey using JME in his classroom to teach students.
What I am saying is: If it is to complicated to get even a small project started it might disencourage (new) users.
On the other side the question is: Who should and want to use the engine ?
Is it more hobby, should it be professional, is it for specialized people (replacing professional stuff) or should it be good and easy enough for pupils and students (like adi.bardas project) ?
I totally agree with you. Trust me. That is why I’m trying to advocate the jME SDK even if for the professionals it is dogfood. But it would be the gate drug to get to jME when a person does not have any clue on any build systems or doesn’t even realize that jME is just a JAR file. It is entirely plausible to have some Java experience and a burning desire to create games but being clueless about Gradle and libraries. And hopefully via SDK (or other really easy start) mature into a healthy contributing adult monkey.
Yes, sad truth too. Currently lacking behind, yes yes. I see the build system being the biggest problem there. It is frankly intimidating to try and get into it. I should try again to convert it to Maven…
I know. But it is the best there is with NB. And it works. Already offers features and ease of use comparable to Gradle. Nothing is sexy there. Netbeans. Outcast. But all may not know that so we might just get away with it
All the other projects trying to create an SDK have failed. The Intellij plugin, dead. All the other non IDE based SDKs also dead as far as I know. It is just a huge undertaking. No matter what is under the hood (bonnet ).
Yes, we could create a setup form similar to LWJGL. If you want to take on that task, please go right ahead.
I still think adding library snapshots to the Engine would be valuable for newcomers. In general, newcomers favor built-in libraries (such as jme3-nifty and jme3-jbullet) over “supplementary” ones (such as Lemur and Minie). Rather than piece together a bunch of unfamiliar libraries that might have incompatibilities, they’d prefer to start with a set that have all been packaged and tested together, even if it’s incomplete and/or not the latest releases.
I had a comparable newcomer experience when I switched from Windows to Linux in 2019. Rather than piece together a bunch of Linux packages, I started with the Mint distribution. It didn’t include the printer support I needed, nor the latest releases of Java and Blender, but it enabled me to boot without knowing anything about kernel versions and package managers.
If someone submits an issue/PR against a snapshot library, we should direct them to the developer’s repo (assuming it’s still maintained) and close the issue/PR.
If the developer’s repo isn’t maintained, then have a choice. We either maintain the library ourselves (in which case issues and PRs would be welcome) or drop the library (in which issues/PRs would be quickly closed).
But this is starting to look like a moot issue. Unless there’s strong support for library snapshots in the Engine, it’s not going to happen.