As said, my approach is the same.
Now, if we want to make something similar (with a gui) from scratch it’s a lot more work than what I did…
We can fork the project sure. but IMO we’ll fight plenty of libgdx specifics and end up having something completely different.
But yeah… let’s try this.
Okay, thanks. That was all the input I needed.
Just wanted to make sure we weren’t dismissing obvious options for political reasons.
I agree with Paul in that, since the tooling is pretty DIY-friendly it mostly comes down to who’s willing to do the work “sell” their own ideal workflow to everyone else 
I don’t know, but is it really too much asked for a programmer to execute a “git clone”? All that it requires is to install git, which is a “probably nice to have” tool if its not yet installed.
There could be a template repository with different branches for different templates. What is still missing is a gradle replacement for the build process anyways. (including iOs and Android)
Or, all templating stuff can be done in gradle itself once you “git cloned” the wrapper and a buildscript
//I reason mainly against super simple one click solutions because of the stuff i missed learning because there where such solutions. And using git + gradle is no rocket science at all.
1 Like
I agree somehow. And I’m not worry about you or other savvy devs around here. You would find your way, even if you had to make the gradle build yourself. So in a way… you are not the target of this “Easy project template”.
I think about total neophites, or even the java devs not familiar with gradle or maven whatsoever. It’s nice to have a push button/easy way to create a working blank project and all its boilerplate and then go straight to the interesting stuff.
Also… we want some continuity with the features of the sdk even if we want to change it. And that’s one of the major features of the SDK.
2 Likes
That’s me back when I installed JME for the first time! 
I wasn’t even using git nor github… but the awesome SDK and wiki made me quickly run the tutorials…
Oh and BTW… another major feature is the ability to run the JME test apps 
1 Like
I agree with everyone :
- providing the quickest path for the newcomer (less steps, less stuff to read)
- providing a solution that could be used by more advanced dev (those that know or take time to read about gradle,…)
- providing choice.
eg of flow (from scratch) :
- install java (8 ?)
- install git (it’s not more work than downloading gdx-setup.jar)
- cd parent
- git clone -b basic_3.1 http://… myproject (every solution listed require to copy/paste a command line, gdx-setup also)
- cd myproject
- rm -Rf .git
now, user as a ready to play project he could start the jme tuto.
he’s free to :
- setup an ide, import the project and refactor
- run gradlew customize (if the template include gradlew and a customize task that could be used to rename package, main class, …)
I have some idea for a simple customize task, or for a simple executable jar that could do the same from customization data stored in the template.
But a important point, in my approach, is to have the simplest way as possible to create a template. maven’s archetype and other system, i tried, are nice (lot of feature, partial template, composition, …) but creating and testing, maintening are pain. (the opposite of my / out today goals)
I agree that maintaining the template is a pain with archetype/scaffolding compared to a github working project that you can start from.
So yeah, pull the project then launch a custom gradlew task that rename packages and all sounds pretty nice…
Also…once that flow works with command lines, We could wrap a GUI over the commands for newcomers.
EDIT : also to illustrate my point of view :
This seems pretty simple for experienced devs.
But see it that way :
uh ok this one I got.
uh… git? mhh ok that’s the thing they use for their project. Do I need it?
oh wow…they mean command line?
Wichcraft!!!
uh oh…ok
Wichcraft!!! what does this do??
Note : I know what all of this does and why it’s needed, but these 6 things do require knowledge in : Java, version control and git in particular, command line, unix shell (or windows btw…).
Of course… if it’s just following a documentation… anyone can do it… but IMO plenty of users will stop at “cd parent”
1 Like
Exactly. Without that you would no see me around here I had/still have very very limited knowhow about Java/Eclipse/Maven/Gradle/Pom/Repos/… If somebody says hey that is now on jcenter then that doesn’t ring any bell, it’s like you guys speak in a language I do not understand.
As well for the graphical stuff. I mean bake something, yeah I can bake a cake, but for graphical stuff no clue.
Long story short: An easy start attracts people, a difficult start scares them away.
1 Like
Well… it also everyone responsability to educate himself. We cannot make documentation about everything related to 3D dev. This “baking textures” is something you can easily google though.
1 Like
Well… I’m no expert in gradle, jcenter & co… but I think that it should be possible that, after making a commit on the template project, have it zipped and sent to jcenter. Then, when building the “wizard”, it grabs this zipped template.
So that when you download and run the wizard you already have the template ready to go… thus not even needing git to begin with (maybe the dev uses Mercurial?)
Java 7 and below are obsolete… not even Oracle supports them anymore.
Yes, every release is automatically zipped when tagged on gitbub.
You get some (usually new) folks who are so strangely and adamantly against any kind of version control.
…and that last line. To dangerous to provide a magic incantation like that to someone who doesn’t really know what they are doing.
Better to just say:
-install Java 8
-download this file
-unzip this file as a new directory for your project
I mean, if we don’t want wrap it in a gui or app or anything that’s at least the easiest way for everyone.
Plus the git clone will pull the entire history for the repo where the template lives. Even if we made a repo just for the template that could still end up being lots of unnecessary downloaded stuff. Especially if we are adding gradlew jars and so on.
Any user that doesn’t know how to install Java/JDK and doesn’t know how to unzip a file and rename the directory really really shouldn’t be doing Java game development.
3 Likes
Agreed.
we already have the zip file github can do it on demand for any commit eg (the “download ZIP” button):
- download https://github.com/jMonkeyEngine-Contributions/project_templates/archive/basic_3.1.zip
- unzip
- rename basic_3.1to myproject
same number of instructions than git. we have the 2 flows ( git allow to do everything from console, for the other flow we need to use curl, wget, or other).
to not download the full history with git:
git clone --depth 1 -b basic_3.1 https://github.com/jMonkeyEngine-Contributions/project_templates myproject
git or curl a matter of taste.
to do everything as a “power user”.
…not really the folks we are talking about. And you left out some git steps. (Download and install git, for example. Do the magic rm .git directory that is dangerous to know without understanding.)
As a power user, I’d have downloaded the template once and have it in an easy to grab location. Or just cut and paste stuff from my last build.
The .git folder is not included in the zip distribution, so it would remove this step.
Downloading & installing git or setup.jar or my-super-project-generator is the same. but
- probability to already have git installed : higher
- probability to already have git is available in a package for user os : higher
- probability to use git later for something else : higher
- git will install itself in the path
So if I should request user to install a tool to generate project, I prefer to suggest git.
I don’t request him to learn and understand git: just to copy/paste the command. (he doesn’t want to read)
But I admit, that for some folks could prefer to download a jar, and run “java -jar xxx.jar …”
1 Like
Yeah, that was a response to david who was suggesting that the git approach was the same number of steps as downloading and extracting a zip.
oh ok sorry, got confused
I didn’t completely read the entire thread, however what about this:
A webpage hosted at jmonkeyengine.org with something like this:
a) a template in the background with the gradle files
b) Some HTML Forms for ProjectNames etc
c) Replace the Variables in the gradle file and offer it as download (maybe even zipped)
That way you only need to visit “jmonkeyengine.org/create_project” and download it.
However for “unexperienced developers”: How should they run or even debug their project when they can’t click on the green arrow? I mean installing git on windows is funny 
So it would better to offer project templates for the “big three” IDEs.
Because: What is the profit to the average developer when using a seperate gradle?
Or how about dependency management? It’s nice to simply add maven entries, however most people will simply download the jar’s and drop them in.
so, mhh not an easy task
Edit: And yeah, linux users aren’t the problem most of the time as you learn to work around troubles and use the command line
I confirm same number of steps (in fact more steps with zip)
with git (4)
git clone --depth 1 -b basic_3.1 https://github.com/jMonkeyEngine-Contributions/project_templates myproject
cd myproject
rm -Rf .git
./gradlew run
with download zip (5 or 6)
curl -O -L https://github.com/jMonkeyEngine-Contributions/project_templates/archive/basic_3.1.zip
unzip -e basic_3.1.zip
mv project_templates-basic_3.1 myproject
cd myproject
./gradlew run
# optional
rm ../basic_3.1.zip