I came on board working on the packager stuff last month. Nearly all of the design decisions for this were made before I came on board, but I will do my best to explain it.
On Wed, Jan 8, 2014 at 8:20 PM, Scott Palmer <swpal...@gmail.com> wrote: > The Java 8 java.exe launcher is now JavaFX aware in that it will launch > JavaFX Applications that don't have a main(String []) method. > The javafxpackager uses it's own launcher when creating a native package. > > Are there plans to unify those launchers? > I noticed a comment under "future work" in WinLauncher.cpp that says "Reuse > code between windows/linux launchers and borrow more code from java.exe > launcher implementation." > The bundler also does a bit more to the JRE as well than just play with the launcher, files not required for redistribution are stripped out wholesale. The web plugin is stripped out, platform specific integrations are stripped out (like the activeX bridge), and every single command line binary entry point is also stripped out (such as rmid, corba services, as well as java.exe and javaw.exe) So we are already do some very non-standard (but legal for re-distribution) things to the JRE. I'm wondering why not make java.exe the only launcher we need. (Or the > javaw.exe variant) I think would mainly be an issue of adding package.cfg > parsing and picking up the embedded runtime. This would require a JEP at the least, and approval from the JSR process since we would be altering a standardized entry point. The cost/benefit goes down quick. > An "application bundle mode" could probably be > triggered via the contents of a resource that is injected much like the > custom icon is injected into the fx launcher (I'm not sure if something > needs to be done for preloader support too. I think the embedded launcher > stub handles that on Java 7, but I believe it isn't used on JavaFX 8. > One of the advantages of our own launcher (as you point out later in your mail) is we can customize the launcher. Put a custom icon on, and (potentially) load up custom meta-data to the executable, and maybe even sign it (we don't sign it today). Tweaking the existing Java.exe in this manner on windows could be problematic. Pre-loader may be handy, but we haven't seen any requests for it yet for app bundles. Post a bug if you would find it useful. > I have been using a standard java.exe launcher from Java 7 for my apps and > hacked jfxrt.jar onto the classpath manually. I do this for a couple > reasons. One because the same app could launch in a Swing or JavaFX mode > while we were transitioning our UI. Two, because we install a private JRE > that is shared among multiple apps and services that make up our product > and javafxpackager only supports the default system-wide JRE or a JRE > embedded into the application bundle. It's a bit too limited... though > after looking at the launcher source, I think I can fool it by making a > "runtime" directory symlink inside the app bundle folder that points to our > company-private JRE. > > I see you posted RT-35215 to address this. Are we talking just windows or windows/mac/linux? We do have a mechanism that isn't widly publicized for userJVMArgs, basically where you can store per-execution jvm args in a file in the app directory. We could include a hook to add a custom JVM home and rely on the installer to set it correctly. > I just started experimenting with the javafxpackager and I noticed that the > .exe that is created could, and probably should, have more things > customized in the resources. If you get properties on the file in Windows > and look at the Details tab, things like Product name and Version are not > filled in. The project has a Title, a Vendor, Description and > Implementation Version, etc. I believe those are used for JNLP deployment. > It would be nice to have those details injected into the .exe just like > the icon is. Should I create an issue for that? > We should populate those, please post a JIRA. > > I'm also curious about the installation location when making a .msi > package. Instead of "Program Files/AppName" or "Program > Files/Vendor/AppName" it goes to the user-specific App-Data folder. This > is almost never what a typical Windows user would want or expect. I > understand it is probably to avoid permission issues, but the installer > really should have had the option to do a per-machine install. > This page > http://docs.oracle.com/javafx/2/deployment/deploy_quick_start.htm > mentions > "Deployment occurs with no need for admin permissions when using ZIP or > user-level installers." .. well how can you make a machine or system level > installer instead? > Is this out-of-scope for javafxpackager enhancements? > > Set the SystemWide flag. Right now it is only accessible via the ant task via the <fx:preferences> element and the attribute is "systemInstall". The default is installer specific (or should be). I expected the MSI to default to system and the EXE to default to this user location you described. (for mac the user install is the desktop. Linux ignores it). Try something like this in ant: <fx:deploy ...your existing deply...> ... <fx:preferences systemInstall="true" ...other preferences attributes... /> ... </fx:deploy> For the gradle plugin it is the 'installSystemWide' attribute of the 'javafx' convention block... javafx { installSystemWide = true } For Maven you cannot access it at the moment. Once I get mu 8u20 changes into a public repo I was going to look into taking the maven plugin over and adding the newer features. > I'm also using only the javafxpackager command line. No Ant tasks. I'm > going for exclusively Gradle-based builds now and I don't want to mix > Gradle & Ant, so I've built a Gradle task that runs the javafxpackager. > Do we have as much power to customize the installer when using the > javafxpackager command line app instead of the Ant task? No, ant and gradle are currently more powerful than the command line tool. I have plans to put in some hooks that will hopefully fix this in 8u20 timeframe. > The javafxpackager > docs that I've found don't get too specific. Most of the docs are assuming > Ant-based builds. (When most people have moved to Maven long ago, long > enough for many of use to hate it now and switch to Gradle :-). ) > Oracle should hire someone to pay attention to the gradle and maven integration... oh wait, nevermind ;) > E.g. Looking at the launcher code I see that it should be possible to > provide any JVM options in the package.cfg file... but I can't find > documentation for this. I see the options in the Ant tasks for jvmargs, > but there doesn't appear to be a way to do it with the command line tool. > > Undocumented but powerful, and you are correct the command line provides no hooks for that. That was a pleasent discovery for me when I started rooting around the code last month. This is likely where I would put the hooks for the shared JRE.
