Deployment

[Cameron O'Rourke]

Daniel, excellent write-up (but then I always appreciate your writings
-- Thank You for your excellent blog, BTW.) You asked us to sound-off,
so: Your option #1 is exactly what I'm looking to do, although right now
my plan is to do something more like #3, along the lines of what was
done with the FX Experience Tools (
http://fxexperience.com/2012/03/packaging-javafx-applications-as-native/
)  My focus is desktop apps, not interested in running inside of a
browser at all. It would be nice to have a standard, documented
procedure for this that doesn't require a $2000 packaging tool.

The bigger challenge, I'm finding, is that once I'm running on the
desktop out of a JAR file or from an Application Bundle on the Mac, I
have to figure out where my resources are, where I can write to the file
system, what system resources and apps can I access (Growl, etc.)

Cheers,
Cameron


Daniel Zwolenski wrote:
> Perhaps we could collectively try and define what the ideal user experience would be in this area and then Igor and Richard can tell us the hurdles that prevent this experience from happening?
>
> Below are the three major deployment scenarios I believe we'd like to have in our arsenal. Please add/correct based on your opinions. 
>
> 1. Web-based install of desktop app
> 2. Web-based launch of Applet 
> 3. Offline distributable of desktop app
>
> For all of these I believe we want a single, minimal-click, minimal-dialog process that installs (if needed), the JRE, JavaFX and the custom app being run. It is not three installs or even two to the user, they are installing one thing only - my custom app. The fact that Java or JFX is needed is not something they want to be overly bothered with. One, end-to-end, simple seamless flow is what the users want. 
>
> I'll get the ball rolling with my view of the ultimate flow for option 1. In this scenario we are trying to achieve a pretty similar experience to what you get when installing an app on a smart phone. Currently webstart is the closest thing to this but it has the flaw that Java needs to be manually installed first. I suggest a plugin that does a smart install of everything. This plugin may well need to be different to the 'applet' plugin, I'm not sure. If it does however, so be it. 
>
> As with normal webstart (and smart phones), option 1 is not so much a webapp as a web-based 'install' of a desktop app - once locally installed it can run offline. 
>
> Here's the sort of flow I'd like to see if the user doesn't have java installed:
>
> - User navigates to the URL for the app in their favorite browser
> - Browser Plugin is triggered
> - Dialog 1: browser's standard, "do you want to install plugin"
> - Plugin is installed and runs
> - Plugin searches for existing JRE, finds none 
> - Dialog 2: says:
>
>     Installing "Daniel's cool application"
>     Developed by Zen Java (more info...)
>     Java will be installed to run this application (more info...)
>     This program requires the following permissions:
>         * Read and write files on your computer
>         * Make network connections 
>     [x] Add shortcut to start menu
>     [x] Add shortcut to desktop
>
> - User hits 'Install' (or 'Cancel' to abort)
>
> - Dialog 3: Combined T&C page for Java + JRE + my custom T&C (preferably one dialog with sections, or as close-to as legals will allow)
>
> - Plugin detects system (not browser) OS and 32 vs 64bit (don't ask user, 90% don't know)
> - JRE+JFX is downloaded and installed (no further input dialogs shown, just a progress indicator)
> - My custom jars (and any relevant bundled native files) are downloaded (same progress indicator as when installing jre)
> - Shortcuts are added to the relevant places
> - Final dialog: Daniel's cool application is now installed. Would you like to launch it now?
>
> From this point on, the user can launch the app from the start menu. A browser is no longer needed (or wanted). Ideally when the app is run it first checks for a new version of Java, JFX, or the custom app online and gives the user the option to upgrade (I feel they should be able to decline). This check is done now by a local pre-launcher, ie the browser/plugin is not involved from here in. 
>
> As far as signing/permissions, I think it needs to be simple. Permissions should be selected by the developer and listed for the user in the same simple approach that smart phones use (eg "write to files on your computer"). Getting a digital certificate is a pain so if there was a way to avoid this or an easier way to do this it would be great - bonus points. 
>
> I would very much prefer it if the automatic Java updates weren't going on all the time in the background. It would be best if the version was just checked on app startup and the user given the option to upgrade. Then they have context. The random 'update your java now' dialog that pops up add-hoc freaks out most users and makes the others angry (including me!)
>
> If in the above flow, a suitable version of java or jfx was found, then the flow would be the same. The difference would be only that on the second dialog, instead of saying "Java will be installed" it says "Using already installed Java" and the 'more info' link then shows details on where it's installed, etc. Then the T&C section would just leave out the Terms for the already installed stuff. Similar if the JRE/JFX needs to be upgraded. 
>
> That would be the optimal UE for option 1 for me. I'll stop there to see what kind of response this gets but options 2 and 3 would take similar tacts.
>
> I'm interested in hearing from the JFX guys what would prevent this from being implemented. Why cant we have this? Are there technical limitations, do you disagree that this is important or would be a better flow, or is it just too much effort?
>
> Just as importantly I'm interested in hearing from all the developers out there. Is this your ideal scenario, is this important to you etc? I raised this issue months ago and the response from the jfx guys was that non-applet, seamless install was too small a use case to warrant the effort needed. I didn't hear anyone chime in to the contrary back then so I don't blame the JFX guys for not moving much in this space. 
>
> Get vocal (on solutions, not just problems). If you want something like the above, say so loud and clear. If you want something different, say that even louder so the rest of us can consider that too and back it if appropriate. There's a top notch team and community at the ready here and for my money this is a make-or-break issue. Let's work this one out together. 
>
> Cheers,
> Dan
>
>
>
>
>
>
>
>
>
> On 20/04/2012, at 2:32 PM, Igor Nekrestyanov <igor.nekrestyanov at oracle.com> wrote:
>
>> On 4/19/12 11:03 PM, Tom Eugelink wrote:
>>> Ok. How about the "there is no standard way to distribute a stand alone JavaFX application"? Create a JIRA issue?
>> Could you please be more specific?
>>
>> What is "standard way" and how do you expect to distribute this package?
>> Is it different problem from distributing java application (especially once javafx runtime will be part of the JRE)?
>> Do you expect to application "install" on the user system or run from the package?
>> Are you thinking about shipping your application to the App Store?
>>
>> We might have related feature request already:
>> http://javafx-jira.kenai.com/browse/RT-19446
>>    "Add ability to co-bundle Java + JavaFX + App into a single native executable"
>>
>> It is on 2.2 list right now but it is not clear if we can support other native packages for platforms other than Mac yet
>> (see discussion in the JIRA).
>>
>> -igor
>>
>