Bootmonkey - bootstrap your JME project

Good job! :slight_smile:

…this bit is a bit funny, because either:

  1. the developer has Java installed. He can as well double click the jar or a link to it.
  2. the developer don’t have Java installed. In this case, he should quit at once, instead of clicking a nice executable and realizing later that he cannot develop in Java without installing Java.

…and besides, bundling a 90Mb JVM would be a bit weird for a bootstrapper.

heheh yep, but I was planning to use packr that allows you to minimize the JRE. Unfortunately it doesn’t work with java 8 and you are not allowed to minimize any oracle JRE. Which force you to use openjdk 8, for which strangely it’s hard to find distributions for all the platforms.

I was also fiddling with all this to have a template build to make native wrapper for games with an embedded JRE… But yeah it’s more complicated that it sounds. A nice solution is javafx bundler, but you need to build your app on the target platform.

Anyway I settled for a fat executable jar for this (not that fat it’s like 6mb). Because as you said… JME users should have a jdk anyway :stuck_out_tongue:

Now this is way more interesting… offer multiple gradle options and allow the dev choose the one he prefers. JavaFX is one option with its pro and cons, and some devs will appreciate that bootmonkey offers it.

Well that’s something for the template project actually, not really bootmonkey. My idea is that monkeys could contribute their own project templates, in a git repo. Of course we would provide basic templates, but the app is build around this idea.

1 Like

Is it unfair to say that the SDK has an easy way of cross platform Distribution?
And also Check that Oracle Clause. You must not Distribute the jdk but the jre was allowed the last time i checked.

You could also use some gradle Wrapper Code they use to find the platform jdk or fail with an error.

hahah, it’s fair. Tbh I’m just trying to get on par with what we had with the SDK.
I’m not trying to be a competition to the SDK. We decided it wouldn’t be a core team support anymore, it was a team decision and I’ll stick to it. You know after Normen i was the one contributing the most to the SDK, but I really believe we need a tool that can be maintained by anyone, not just a chosen few that are crazy enough to dive into netbeans API.

About Oracle JRE, I think you are not allowed to bundle it modified (like with removed classes) and that’s what Packr does (there is a comment about it in their issue tracker). Anyway idk.

2 Likes

Kirill would be proud.
No, not @Momoko_Fan, this one @kirillcool :slight_smile:

This is great,but i can’t understand how the variable {jmeVersion} is defined…can’t we specify a jme version in the YAML file or when we boot the project in the tool?

yeah … you can’t actually, it’s hard coded. I planned to have it in the little ui, but didn’t do it in the end.
You just have to change it in the generated project’s build.gradle though.

I’m making a PR that adds a little menu to modify hardcoded settings,could you please review and (if it’s ok) merge it?

3 Likes

yep, will do :wink: thanks

1 Like

Thanks to @aegroto this setting is now available when creating a project, I’m gonna push a release today

1 Like

And done Release Bootmonkey 1.0.0 · Nehon/bootmonkey · GitHub
Also tagged the template project as 1.0.0
GitHub - Nehon/base-jme at 1.0.0

I’m very open to any suggestions to make this better

3 Likes

Hi … I tried BootMonkey. Seems like a cool idea. However, I didn’t find it intuitive to use. So, here are some comments from a lounge-sofa java programmer.

  1. The app does not create a project that the SDK will open. No nice little monkey face in the SDK file list where you choose files to open. Maybe it’s missing a nbproject directory with required XML files? Is this template available? I know it’s supposed to be IDE agnostic, but I don’t see how to import the generated project into the SDK. There is no import option for this project type in the SDK.

  2. Template: Neither Snapshot nor 1.0.0 seem to make any visible difference. Am I missing something?

  3. Default package ends up being main.java.org.alfinete.blahblahblah. I would think that it should be org.alfinete.blahblahblah as in SDK.

  4. There is also a Resource folder in the src folder. Is this for Android resources?

  5. I think it needs a help button to open a readonly TextArea with basic help topics, such as mentioning what each button does or means. Things are not totally obvious.

  6. Maybe the documenation should say that if you use the SDK, you shouldn’t use bootMonkey. Or maybe, it should mention exacly WHY you would choose to use BootMonkey. Since I don’t use Eclipse or IntelliJ, I can’t say if the generated project can be imported into those IDEs.

I hope those comments are helpful.

Cheers.

PS. Maybe it’s not for lounge-sofa java programmers. Hahaha.

well… kind of the point, If you use the SDK in the first place you don’t need bootmonkey. But if you really want to do it you need Gradle support in the sdk (which is a netbeans plugin you can install).

Yep the 1.0.0 is actually the last commit in the template so basically SNAPSHOT=1.0.0. But if there are new commits made in the template before a release the point is to be able to create a project from them.

That’s because you don’t have gradle support, and that’s a prerequisite to use this template. This is standard maven/gradle project structure. Your source java source folder is basically main.java.

This is standard maven/gradle project structure

mhh ok. maybe I’ll add it, but more in the project readme.md, not directly in the ui.

You can use bootmonkey if this talks to you. Else you’d better stick with the SDK.

Thanks for clarifying those points.

The mini2Dx version of 1.0.7 no longer exists and they can no longer use appBuilder MacOs due to it being removed from maven and all other repos.

To fix this I updated the mini2Dx version to 1.4.0 in the build.gradle.
I updated the files Proto.java and MainWindow.java to default to 3.2 of the engine.

I have a PR waiting if you OK these changes.

1 Like

can we use it for JME 3.3?

If you clone the project and fix the compilation errors, yes.

I still use it myself.

1 Like

I found something in the store and use that. But this bootmonkey is like more familiar with the sdk.