Build actually looks pretty simple - yeah, sure you need 3 SDKs, that's not really much different to how JavaFX used to be (2 SDKs and separate packaging tools). After you get them installed, just fire up a script it sounds like and it should be boom, ready to go.
I'll try this with Parsetool first, then try Dicetool (should be simple if I can get Parsetool working). Then maybe Tokentool. Then maybe more Dicetool fixes :
- Parsetool Android Port - not done
- Dicetool JFX Port - not done
- Dicetool Android Port - not done
- Tokentool - not done
- Maptool - not done
(Btw, just a little teaser - sounds like iOS should actually be a potential target - turns out somebody's been building Java onto iOS devices...)
EDIT: Developer note - ok, first roadblock I hit - couldn't deploy to my Android device, period. Turns out...IntelliJ in its current form (still confirming, but the theory fits the facts) can't pass ENV vars to gradle, which uses those to select and android sdk...I have two installed - my old one can't see my device, my new one can. My new one can deploy to my device, my old one can't. My build doesn't say anywhere which Java/Gradle/Android SDK combination its using (major problem if you ask me, although gradlew is at least a godsend for reproduceable builds). And there is no way to set (today) your env vars for your gradle script from IntelliJ. Maybe this is because the gradlew script blocks them? No idea. Just a big fat warning, this is an issue. If you've got an sdk that works, check for an ANDROID_HOME and an old android sdk installation.
EDIT2: Forget JavaFX/Gradle - there generally is a big issue with the android tooling in general - Android Studio is Google's attempt to hide the ugly from everyone...but there's a lot of work left to be done making the tooling seamless.
EDIT3: Got JavaFX+Gradle+Android working, with two different SDKs (Dalvik and Gluon). Gluon seems like the slicker experience, of course they're paid. They offer open source license though. Dalvik is free...but I get the sense they stopped developing it. It uses a really, really old Android API (which I guess is great if you're all running crap phones/tablets).
Gluon just ran with gradlew androidInstall (I still had to start it manually).
I'll be working on integrating parsertool next.
- To build the java app (with gradle) you pretty much have to use the java plugin. Makes sense, alright.
- To build the android app (with gradle) you pretty much have to use the android plugin. Makes sense, alright.
- You cannot use the java and the android plugins together.
I'm not sure what that means for the eventual port...but that alone will make any JavaFX -> Android port a hairball. I think I can solve this, and I was planning on doing this already - but I think I'm going to need 3 modules, one android, one java one common, and the java/android ones will be thin wrappers around the base module. Yay multi-module gradle apps...
I'm going to take a break for a couple hours here...maybe something will come to me.
EDIT5: Android/Java Hybrid project is setup. I think it works...haven't really tested anything. Project workflow needs ironed out...but I have bigger fish to fry.
Android has a big issue, (which I sort of already knew about) - Java 7 was the last real supported version by the Dalvik VM, the Ensemble stuff in the javafx-dalvik SDK uses retrolambda to target Java 8 and backport it to dalvik - so basically its a hack. Not only that, the build task is a hack... it does 'work' but the sample project uses a jar that's hard coded into a hacked up version of the retrolambda task. There's a new plugin version of retro...so my thinking is I just have to play around with the build file a bit. I'm about 95% confident that I can get a dalviked version of the build in here...
Gluon is probably a no-go. They have a complicated Desktop/Mobile strategy - it probably works great, but you probably also have to buy wholesale into their stuff - which, granted, I'm pretty darn sure the scenebuilder they provide and the one inside IntelliJ are one and the same, so maybe its not that bad...but the way gluon projects are structured you basically become a gluon app, not a java app with a gluon transmogrifier. That being said, I think its worth it to look at the plugin, and see which dependencies they have. I'm not advocating whole-sale RE...just seeing their general strategy, as its probably worth copying.