I want to export my project to run on Mac as a .app file and Windows as a .exe file. Does jme do this for me? Or does eclipse do this? Or do I have to export it as a jar and then use OS X Application bundle and some third party thing for windows? Thanks!
The SDK 3.0 can do it and the SDK 3.1 can do it even better.
Note: For more experienced stuff it’s never wrong to learn about launch4j which is what the SDK is doing for you
1 Like
There also is a nice wiki entry:
http://jmonkeyengine.github.io/wiki/sdk/application_deployment.html
1 Like
I don’t want to spread FUD, but on one occasion a snapshot build from the master branch failed it for me.
The SDK is cool in that you quickly get an executable; however if you plan to actually publish the game you do want to have gradle manage it properly with bundling a JRE… I think gradle is the way forward.
Has nothing to do with gradle… The 3.1 SDK uses the official Oracle deployment method and allows to bundle the JRE.
Yeah, I know about launch4j. Thanks!
This is technically true, however
So I’m using an alternative deployment plugin. While we’re at it, big kudos for making a deployment one-click solution that works for all platform 
Still doesn’t have anything to do with gradle. Gradle doesn’t supply any desktop deployment and any desktop deployment for gradle wouldn’t depend on gradle.
Hi
JDNT, my Ant-based tool, is able to create OS X .APP bundles, Microsoft Windows .exe (NSIS installers) executables and DEB+RPM GNU Linux packages. It’s more cross-platform than Oracle javapackager as it doesn’t require to be under the target platform to generate the packages, i.e you can create the Windows executables under GNU Linux with my tool 
This very last feature is very recent, I added it into my tool a few days ago.
The 3.1 SDK ANT targets can also deploy from any platform to any other (and automatically download and bundle the JRE for each platform). It still uses the Oracle stubs though.
You’re probably talking about those stubs:
https://github.com/jMonkeyEngine/sdk/tree/master/jme3-desktop-executables/desktop-deployment-data
It seems to work a bit like PackR, i.e it creates a ZIP or APP archive with an executable to run the program, maybe it’s enough for the original poster’s need but it doesn’t produce really native bundles except for Mac and a ZIP archive isn’t the same thing than the NSIS executable installer generated by JNDT. When a developer needs a single executable instead of a ZIP, JNDT is a better choice.
Look at Oracle’s stuff
https://blogs.oracle.com/talkingjavadeployment/entry/native_packaging_for_javafx
What I said is that the 3.1 SDK deployment can create executables for any platform on any platform. Actually we just created the stubs from the JavaFX deployment for each platform, packaged them in the file you reference and then create the appropriate folder structure and config files, (optionally) download the JRE and place / reference it as well. As for installers, you can then choose to use any installer that you want, including deployment via app stores, steam and the likes - which don’t work well with actual installers.
I don’t know what you mean by “really native bundles”, how much more native than a platform-specific executable can it get? Having the libraries appended to the executable doesn’t make it “more native” imo.
2 Likes
In my humble opinion, just putting everything into a compressed archive is enough as a fallback or for technical users but those archives don’t look like native softwares for the target platform except for .APP under OS X. I prefer that the end user installs the software with an installer that is familiar to her/him and launches it in the usual way, with no archive to decompress, just one or two clicks, maybe a few more clicks if unsigned and that’s all. Making an effort to provide softwares packaged in a familiar way for end users and providing a deeper native integration (desktop and start menu shortcuts, clean uninstall, …) go far beyond “Having the libraries appended to the executable”.
Anyway, it’s possible to use the content of those compressed archives to create installers. What JMonkeyEngine provides is better than nothing but I think that there is some room for improvements. It can be solved by third party libraries and tools outside of JMonkeyEngine too, that’s why I dare to suggest mine.
Actually the fact that the end result is put in a ZIP is due to the fact that not all platforms (looking at you, windows) keep executable flags in their file system. In a ZIP they are kept. The developer can do with the content what he wishes to do, as you say create an installer for example. But as said, installers are on the way out imo, especially “platform independent” ones. People publish their games for example via steam which requires you to have a folder that can be delta’d.
1 Like
I didn’t know this requirement of Steam. What do you mean by “installers are on the way out imo, especially “platform independent” ones”? I know that numerous developers use centralized application stores even though this isn’t a trend I approve.
If you approve it or not, users also see the benefit in a centralized way to update and install their applications. Plus the OSs also get more closed/secure in many respects, making it harder to use platform independent installer systems. Most every OS has their preferred installer system. Especially Linux users are quite reluctant to use anything but the package manager to install software, and for good reason.
1 Like
There is a huge difference between a package manager and an “application” store. The package manager doesn’t prevent the end users from installing unsigned packages or “unofficial” packages, it’s up to the end users to decide, the developers don’t have to pay to submit her/his softwares to a centralized repository, it’s possible to add alternative repositories whereas the application store has much more constraints and may give a false impression of security (it’s unfortunately totally possible to install a software full of malwares by using such a store). A software can be removed from it for technical or political reasons, the “gatekeeper” decides.
JNDT produces Windows installers and uninstallers, a bundle produced by JNDT can be uninstalled in the same place than any other software under Windows (“Add or Remove Programs”). It produces RPM and DEB packages that GNU Linux users can install and uninstall like any other packages. That’s the point of using JNDT, it’s a platform independent tool producing platform dependent bundles… and it’s possible to sign the resulting compressed archives and bundles to submit them to those stores except that I don’t produce APPX files yet.
Well I didn’t say anything about any of those things. This exchange started when you stated that the Oracle deployment only works for the platform its run on, which is not true for the SDK deployment despite the fact that it does use Oracles deployment method.
As for your installer system, if its based on ANT it can be easily used by SDK users if they wish to do so. I still see most commercial game projects go the way of Steam though, in which case it won’t give any additional benefit whatsoever.