Comments inline… On Jan 10, 2014, at 12:11 PM, Danno Ferrin <danno.fer...@shemnon.com> wrote:
> 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. > > > I'm wondering why not make java.exe the only launcher we need. ... > > 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. > > ... > 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. Understood. Sounds like it best to keep them separate. > > 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. Consider RT-33594 .. I considered a Pre-loader the best place to put any splash screen code. Applications with large startup times might want to have a unified mechanism to show the user that the app will be ready shortly. I see no reason to differentiate between a web-start app that is downloading jars or any other startup delay. For example my app scans the disk for plugins and loads them prior to showing the main UI. > > > 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? I am doing this on Windows currently. We also have some OS X support but currently require Java to be installed independently. That needs to be cleaned up at doe point. We will be running both a service and a couple applications on OS X as well so using a single company-private JRE would make sense there too. > 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. That works for me. I already discovered the jvmarg thing in the package.cfg file. There are some class path bugs with the Java launcher stubs that I had to work around by adding something to app.classpath in that file. It was related to the jar used for my log formatter not being loadable by the logging system when launching JavaFX apps. While I was there I used the jvmargs to set the java.util.logging config file property. > > 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. RT-35271 > > > 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). That’s why I missed it, I was using the command-line javafxpackager. On Mac desktop probably makes the most sense. (I personally make an Applications folder inside my user dir.. the system is smart enough to give the folder the same icon as the system-wide Applications folder.) > > 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 just started using the gradle plugin from https://bitbucket.org/shemnon/javafx-gradle today. Is that the one you are referring to? It would be great to see official support at the same level as the Ant support. Specially now that OpenJFX is Gradle-based as well. > > 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. Now that I have found the Gradle plugin, I personally would rather have the attention go in that direction. But certainly the javafxpackager command-line tool would would benefit greatly from access to a few more features of the packaging process. > > 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 ;) :-) +1 I’m totally on-board with Gradle. We have a complicated build process. We started years ago with Ant, moved to Maven (hell), and finally found Gradle. Gradle rocks! We found this to be very true http://nealford.com/memeagora/2013/01/22/why_everyone_eventually_hates_maven.html > > 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. Looks like 8u20 is going to be the release where JavaFX really shines. I have to deliver on 7u45 for now and I think 8 is going to be just irritating enough that I will try to skip it. ;-) When I mentioned to a colleague that I could go straight to an MSI installer from the javafxpackager they were sufficiently impressed. We likely will need to customize the installer too much to actually use that feature in production, but I really like having it. Just getting the app bundle correctly laid out so it is ready to go helps too. Thanks, Scott
