FEATURE: New build/deploy process

Developer discussion regarding MapTool 1.4

Moderators: dorpond, trevor, Azhrei

Forum rules
Posting now open to all registered forum users.
Post Reply
User avatar
JamzTheMan
Great Wyrm
Posts: 1872
Joined: Mon May 10, 2010 12:59 pm
Location: Chicagoland
Contact:

FEATURE: New build/deploy process

Post by JamzTheMan »

I wanted to start a new topic to discuss how MapTool (and TokenTool and other *Tool's) are built and distributed.

We've discussed this some in other threads (so mods feel free to move/redirect those here) but lets decide on how we want to release 1.4 here.

I just submitted a POC via a new build.gradle script for TokenTool and is in GitHub. It has 2 new command sets:

1. fatJar :: Standard gradle command to package TokenTool into a single Jar (no external lib directories/install/run script needed)

2. launch4j :: Builds a Windows .exe by wrapping the single Jar and displays a splash screen while launching. (Uses Launch4j opensource project to accomplish this)

I'd like to do the same for MapTool, and only started with TokenTool as it's less complicated for a POC. Also, for a second stage POC, I could embed a JRE for TokenTool as this is available in Launch4J (it also searches for min/max versions and can display errors/download links if JRE is missing if not bundled).

Now, for Linux/Mac, not sure what we can do here? Leave as .app for Mac and leave .jar for Linux? Mac is more locked down and I have 0 experience with it. And my gut feeling is that Linux users already are "advanced" users and typically are fine with installing JRE's etc. It's really the Windows user base that vary widely from "What is a JRE? Do I double click or single click this thing?" to "Dang it, let me use my own Open JDK! just give me the source code and I'll compile my own jar..."

And/Or we could bundle a JRE and have specific jars for all 3 platforms (as each needs it own specific JRE). We already handle Mac specifically so we're just splitting Linux/Window jars here. There are other products out there that do this better, but I couldn't find any that does it all (creating native executables, bundle jre, single jar solution).

Last alternative is using a tool to create an "Installer" but I'd prefer to keep MT portable. Who doesn't love running a single file program off a USB stick when needed? Especially for those "work" laptops that you can't install on! :)
-Jamz
____________________
Custom MapTool 1.4.x.x Fork: maptool.nerps.net
Custom TokenTool 2.0 Fork: tokentool.nerps.net
More information here: MapTool Nerps! Fork

User avatar
Azhrei
Site Admin
Posts: 12086
Joined: Mon Jun 12, 2006 1:20 pm
Location: Tampa, FL

Re: FEATURE: New build/deploy process

Post by Azhrei »

Hm. Do you need an executable for Windows users? If you ship them a fatJar and that JAR starts the MapToolLauncher (so that memory settings can be made), isn't that sufficient?

In terms of embedding a JRE, you're right that it's going to be platform-specific. No way around it. (Although I compiled some C code on Linux recently and it executed on OS X without recompiling! Shocked the hell out of me! I figured libraries would be all wrong. Some day I'm going to have to investigate exactly what happened there.)

Since we're going to have different bundles for each platform, we may as well use the platform's facilities (.app on OS X, .jar on others).

I'll try to answer OS X questions if I can. I know nothing about Gradle other than a couple of web articles I've read. Time to try it out, I guess.

(I still need to wipe all traces of Java from my MacBook Pro and start over. I screwed something up pretty good, I think.)

User avatar
aliasmask
RPTools Team
Posts: 9024
Joined: Tue Nov 10, 2009 6:11 pm
Location: Bay Area

Re: FEATURE: New build/deploy process

Post by aliasmask »

I think an .exe file for 32bit and 64bit windows versions would be nice if you're going to embed the jre. One thing is you can pin the .exe to the windows task bar for easy access. Adding the jar file is a lot more difficult.

User avatar
JamzTheMan
Great Wyrm
Posts: 1872
Joined: Mon May 10, 2010 12:59 pm
Location: Chicagoland
Contact:

Re: FEATURE: New build/deploy process

Post by JamzTheMan »

aliasmask wrote:I think an .exe file for 32bit and 64bit windows versions would be nice if you're going to embed the jre. One thing is you can pin the .exe to the windows task bar for easy access. Adding the jar file is a lot more difficult.
This. Sure, we can use jar files ok but exe files have more options. You also dont risk file association, like an unzip program taking over as a default option for .jar files. Plus you get icons and feels more like a real program.

Gradle is just the new ant. You can do most of this without gradle but with plugins it does help automate the process. Craig did a great start on the build file. With one command MT now builds a distro.

hmm, wonder how easy is to set up ftp...
-Jamz
____________________
Custom MapTool 1.4.x.x Fork: maptool.nerps.net
Custom TokenTool 2.0 Fork: tokentool.nerps.net
More information here: MapTool Nerps! Fork

User avatar
wolph42
Winter Wolph
Posts: 9999
Joined: Fri Mar 20, 2009 5:40 am
Location: Netherlands
Contact:

Re: FEATURE: New build/deploy process

Post by wolph42 »

from what I've learned on this forum and certainly if I look at mote. OFTRTA (One file to rule them all) is a must if you want to give MT a future. Mote applies oftrta and I have to say its very convenient to just have 'mote.exe' and thats it, no java installs, no install directories (there is still the .mote dir) hit and go.

that said. I still would keep a .jar if not alone so I can choose to run j32 or 64. and probly other reasons for the more tech savvies to play around with it.That and it would probly be a pain for intermediate test versions to create all the different builds. So once in a while build... lets see:

- core (so .jar)
- linux
- OSX (.jar)
- win 32 (.exe)
- win 64 (.exe)
- ...?

User avatar
JamzTheMan
Great Wyrm
Posts: 1872
Joined: Mon May 10, 2010 12:59 pm
Location: Chicagoland
Contact:

Re: FEATURE: New build/deploy process

Post by JamzTheMan »

Yep. Which is why I started building my TokenTool build that way last year. So much more convenient.

And once it's set up, We can pretty much build all those versions for each build. It's automated with gradle.

edited Checked again and yes Windows will require separate x64 & x32 bit versions. Do we need 32bit versions for linux/MacOS?
-Jamz
____________________
Custom MapTool 1.4.x.x Fork: maptool.nerps.net
Custom TokenTool 2.0 Fork: tokentool.nerps.net
More information here: MapTool Nerps! Fork

User avatar
RPTroll
TheBard
Posts: 3159
Joined: Tue Mar 21, 2006 7:26 pm
Location: Austin, Tx
Contact:

Re: FEATURE: New build/deploy process

Post by RPTroll »

Task 33
33 New build/deploy process core POC Jamz 4/1/2015 http://forums.rptools.net/viewtopic.php?f=86&t=25880 Distinct file for each platform .exe for pcs, .app for Mac, .jar for Linux and folks that like running jars.
ImageImage ImageImageImageImage
Support RPTools by shopping
Image
Image

Craig
Great Wyrm
Posts: 2107
Joined: Sun Jun 22, 2008 7:53 pm
Location: Melbourne, Australia

Re: FEATURE: New build/deploy process

Post by Craig »

In one way I prefer the JavaFX packager (when we get there) as it allows us to do all platforms with included JRE, where as other methods don't.
On the other hand its a pain in the something I can't write on this board because it will be censored because it means you have to build once on each platform...

User avatar
JamzTheMan
Great Wyrm
Posts: 1872
Joined: Mon May 10, 2010 12:59 pm
Location: Chicagoland
Contact:

Re: FEATURE: New build/deploy process

Post by JamzTheMan »

Ya, I looked at the JavaFX as well and agree, it seemed....messy.

There seemed to be easier options with other plugins...
-Jamz
____________________
Custom MapTool 1.4.x.x Fork: maptool.nerps.net
Custom TokenTool 2.0 Fork: tokentool.nerps.net
More information here: MapTool Nerps! Fork

User avatar
JamzTheMan
Great Wyrm
Posts: 1872
Joined: Mon May 10, 2010 12:59 pm
Location: Chicagoland
Contact:

Re: FEATURE: New build/deploy process

Post by JamzTheMan »

OK, so I spent the last few days looking at various packaging options for MapTool, with the goal of simple launch, no external steps (ie install JRE), builds for all 3 OS types (Windows, MacOS, Linux).

As I deal with this personally with my own group, and even after repeated lessons and telling them to not update Java, I constantly field questions, "My MapTools stopped working...", and after investigation, it is usually due to Java updates.

Given I can not even get 5 out of 6 of my players to do what is necessary to keep MapTool running, it would seem this would be a common problem with MapTool and the Internet and can only imagine how many people walk away from this awesome tool because of it. With that said...on to the analysis...


There are 3 basic options:
1. Fat/Executable JAR's
2. AOT Compilers
3. JRE Packager's/Installers


1. Fat/Executable JAR's
Pros: These are great, you get one JAR, you double click and it launches. Same process for Windows/Linux.
Cons: You still require a JRE pre-installed and can break if installed JRE gets out of sync.


2. AOT Compilers
Pros: Ahead Of Time compilers take Java byte code and compile it to Native code for a given OS. This means no JRE is used. Excellent memory management and faster execution.
Cons: Licensing. There is a GNU version that has been in the works for a while but no windows AWT/Swing support. I tried a demo of Excelsior JET, and it seemed to work great (only tested for Windows), but you have to request a free license for Non-Commercial Use. I'll leave that to the powers to be if RPTools wants to pursue but I suspect it doesn't play well with our open source license?


3. JRE Packager's/Installers
Pros: This is the most popular choice (with most free options available). While nothing really packs the JRE inside the application, they are basically various forms of installation of given JRE's along with your application.
Cons: Various levels of success, various OS integration's, support based on popularity of solution (most do not have a huge user base/support model).


After trying #1 and #2, I concentrated on #3.

a. Capsule
Pros: Open source solution. It's main use is creating a single Far/Executable JAR. Along with Capsule-Desktop, it produces executable jars for all 3 OS types.
Cons: Doesn't package JRE. Linux failed to launch automatically, didn't test MacOS.

b. Launch4J
Pros: Open source solution. Great support. Lots of configuration options. Gradle Plugin.
Cons: Only creates Windows executable. Can use a packaged JRE but you have to package it up yourself.

c. Various installers
Pros: Most created installation packages for targeted OS's
Cons: Most are enterprise solutions (not free) with various levels of complexity.

d. JWrapper
Pros: Free to use version, requires JWrapper logo use (couldn't find exact licensing, not sure if it conflicts with our licence?). Creates executable's for all 3 OS types. Packages/compresses JRE for you (following Oracle standards). Creates launchers that download appropriate JRE (or use existing), stores in AppData directory so less confusion for user. Defaults to use supplied JRE only. Can auto-update. Creates both x32 & x64 bit versions. Tested on WIndows and Linux ok. It can also sign the package using JKS key. Creates Start menu icons/uninstaller.
Cons: Possible license issue? Currently sorting through dynamic JVM options issue.



Conclusion: I found JWrapper to be the best overall solution for now. I've created a test version off a test build to play with and can be found at the link below. I really do like this package. You set your configuration via an XML file and the build can be called via command line (so it can be integrated into Gradle). It worked on Windows 10, Windows 8.1, and Debian Linux (my test machines). If someone wants to test the MacOS version, I'd appreciate it.

Currently I have it set to auto-update (my preferred solution for my players) but it can be turned off. By default it's a silent/auto update but there is an API so you could do a "prompt user" or at least let them know an update is available.

The offline installer is less than 50mb. The online installer is less than 2mb which then downloads the rest of the application and JRE's. (not much difference really. The advantage would be if you allowed installed JRE to be used it would skip that but they do such a great job of compressing the JRE I see no reason not to force a supplied version for support reasons)

To test, go to: http://maptool.nerps.net
-Jamz
____________________
Custom MapTool 1.4.x.x Fork: maptool.nerps.net
Custom TokenTool 2.0 Fork: tokentool.nerps.net
More information here: MapTool Nerps! Fork

User avatar
aliasmask
RPTools Team
Posts: 9024
Joined: Tue Nov 10, 2009 6:11 pm
Location: Bay Area

Re: FEATURE: New build/deploy process

Post by aliasmask »

Nice. This will solve 80% of the problems encountered for new users trying to start MapTool. The other 20% is left to networking issues starting a server.

User avatar
Jagged
Great Wyrm
Posts: 1306
Joined: Mon Sep 15, 2008 9:27 am
Location: Bristol, UK

Re: FEATURE: New build/deploy process

Post by Jagged »

JWrapper looks interesting. Searching the internet, it seems to have favourable reviews and has been around since 2013. I like that it handles the signing issues, that can be the biggest pain. Looks like there's a Maven plugin too.


User avatar
JamzTheMan
Great Wyrm
Posts: 1872
Joined: Mon May 10, 2010 12:59 pm
Location: Chicagoland
Contact:

Re: FEATURE: New build/deploy process

Post by JamzTheMan »

wolph42 wrote:coolbeans. checked it out and it worked. I was just wondering how you set the memory settings with this method?
Currently it's baked into the executable (Xmx4096 and Xss3m). I'm still looking to find how to set JVM settings dynamically but haven't found any settings yet.

It must be possible and it's the last sticking point. It may have to be done via the API.
-Jamz
____________________
Custom MapTool 1.4.x.x Fork: maptool.nerps.net
Custom TokenTool 2.0 Fork: tokentool.nerps.net
More information here: MapTool Nerps! Fork

Post Reply

Return to “MapTool 1.4”