Re: javafxpackager and launcher
What I'm referring to is data that is already available to the packager that is not being used effectively. It's only applied to JNLP data or something, when it can also apply to the resources in the launcher exe. I think the two issues are distinct. Scott On Fri, Jan 10, 2014 at 5:23 PM, Mark Fortner wrote: > Comments in-line > > >> >> 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? >> >> > I think there already is an issue for a "universal deployment descriptor" > https://javafx-jira.kenai.com/browse/RT-29229. > > This came out of last year's discussion thread entitled "Packaging > Application Metadata". > > Cheers, > > Mark >
hg: openjfx/8/graphics/rt: 2 new changesets
Changeset: 2872be3a2984 Author:hudson Date: 2014-01-10 09:30 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/2872be3a2984 Added tag 8.0-b123 for changeset 423cf238579d ! .hgtags Changeset: 9689bfae29b8 Author:mv157916 Date: 2014-01-10 15:05 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/9689bfae29b8 RT-35268: Update the JDK 8 build number to b123 in rt/build.properties file in the JavaFX 8 Master forest. ! build.properties
hg: openjfx/8u-dev/rt: 6 new changesets
Changeset: 26f87c5d3435 Author:hudson Date: 2014-01-03 06:56 -0800 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/26f87c5d3435 Added tag 8.0-b122 for changeset dd789066e61e ! .hgtags Changeset: 44acc56c806e Author:mv157916 Date: 2014-01-03 13:32 -0800 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/44acc56c806e RT-35171: Update the JDK 8 build number to b122 in rt/build.properties file in the JavaFX 8 Master forest. ! build.properties Changeset: 5aca75258738 Author:Rafi Tayar Date: 2014-01-06 11:23 +0200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/5aca75258738 RT-34744 [Touch, Lens] Scrolling is only possible using scroll bars Reviewed-by: dblaukop kcr jgiles ! buildSrc/armv6hf.gradle ! buildSrc/armv6sf.gradle ! buildSrc/x86egl.gradle ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ListViewSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TableViewSkinBase.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TreeViewSkin.java Changeset: 423cf238579d Author:Yves Joan Date: 2014-01-07 12:06 +0100 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/423cf238579d Sync up SceneBuilder changes ! apps/scenebuilder/SceneBuilderApp/src/com/oracle/javafx/scenebuilder/app/AppPlatform.java ! apps/scenebuilder/SceneBuilderApp/src/com/oracle/javafx/scenebuilder/app/SceneBuilderApp.java ! apps/scenebuilder/SceneBuilderApp/src/com/oracle/javafx/scenebuilder/app/SceneBuilderTest.java ! apps/scenebuilder/SceneBuilderApp/src/com/oracle/javafx/scenebuilder/app/ScenicViewStarter.java ! apps/scenebuilder/SceneBuilderApp/src/com/oracle/javafx/scenebuilder/app/i18n/SceneBuilderApp.properties ! apps/scenebuilder/SceneBuilderApp/src/com/oracle/javafx/scenebuilder/app/menubar/MenuBar.fxml ! apps/scenebuilder/SceneBuilderApp/src/com/oracle/javafx/scenebuilder/app/menubar/MenuBarController.java - apps/scenebuilder/SceneBuilderApp/src/com/oracle/javafx/scenebuilder/app/preferences/PreferencesDialogController.java - apps/scenebuilder/SceneBuilderApp/src/com/oracle/javafx/scenebuilder/app/preferences/SBPreferences.java ! apps/scenebuilder/SceneBuilderApp/src/com/oracle/javafx/scenebuilder/app/preview/PreviewWindowController.java ! apps/scenebuilder/SceneBuilderApp/src/com/oracle/javafx/scenebuilder/app/template/FxmlTemplates.java ! apps/scenebuilder/SceneBuilderKit/src/com/oracle/javafx/scenebuilder/kit/editor/EditorController.java ! apps/scenebuilder/SceneBuilderKit/src/com/oracle/javafx/scenebuilder/kit/editor/EditorPlatform.java ! apps/scenebuilder/SceneBuilderKit/src/com/oracle/javafx/scenebuilder/kit/editor/i18n/SceneBuilderKit.properties - apps/scenebuilder/SceneBuilderKit/src/com/oracle/javafx/scenebuilder/kit/editor/images/ImageUtilsBase.java ! apps/scenebuilder/SceneBuilderKit/src/com/oracle/javafx/scenebuilder/kit/editor/job/ModifyFxIdJob.java + apps/scenebuilder/SceneBuilderKit/src/com/oracle/javafx/scenebuilder/kit/editor/job/UsePredefinedSizeJob.java - apps/scenebuilder/SceneBuilderKit/src/com/oracle/javafx/scenebuilder/kit/editor/panel/content/gesture/mouse/ResizeShadow.java - apps/scenebuilder/SceneBuilderKit/src/com/oracle/javafx/scenebuilder/kit/editor/panel/hierarchy/ImageView.fxml ! apps/scenebuilder/SceneBuilderKit/src/com/oracle/javafx/scenebuilder/kit/editor/panel/hierarchy/treetableview/HierarchyTreeTableCell.java ! apps/scenebuilder/SceneBuilderKit/src/com/oracle/javafx/scenebuilder/kit/editor/panel/hierarchy/treeview/HierarchyTreeCell.java ! apps/scenebuilder/SceneBuilderKit/src/com/oracle/javafx/scenebuilder/kit/editor/panel/inspector/InspectorPanelController.java ! apps/scenebuilder/SceneBuilderKit/src/com/oracle/javafx/scenebuilder/kit/editor/panel/inspector/editors/AutoSuggestEditor.java ! apps/scenebuilder/SceneBuilderKit/src/com/oracle/javafx/scenebuilder/kit/editor/panel/inspector/editors/BoundedDoubleEditor.fxml ! apps/scenebuilder/SceneBuilderKit/src/com/oracle/javafx/scenebuilder/kit/editor/panel/inspector/editors/BoundedDoubleEditor.java + apps/scenebuilder/SceneBuilderKit/src/com/oracle/javafx/scenebuilder/kit/editor/panel/inspector/editors/ColumnResizePolicyEditor.java ! apps/scenebuilder/SceneBuilderKit/src/com/oracle/javafx/scenebuilder/kit/editor/panel/inspector/editors/CursorEditor.java ! apps/scenebuilder/SceneBuilderKit/src/com/oracle/javafx/scenebuilder/kit/editor/panel/inspector/editors/EditorUtils.java ! apps/scenebuilder/SceneBuilderKit/src/com/oracle/javafx/scenebuilder/kit/editor/panel/inspector/editors/EnumEditor.java ! apps/scenebuilder/SceneBuilderKit/src/com/oracle/javafx/scenebuilder/kit/editor/panel/inspector/editors/EventHandlerEditor.java ! apps/scenebuilder/SceneBuilderKit/src/com/oracle/javafx/scenebuilder/kit/editor/panel/inspector/editors/FxIdEditor.java ! apps/scenebuilder/SceneBuilderKit/src/com/oracle/javafx/scenebuilder/kit/editor/panel/inspector/editors/I18nStringEditor.java !
Re: javafxpackager and launcher
Comments in-line > > 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? > > I think there already is an issue for a "universal deployment descriptor" https://javafx-jira.kenai.com/browse/RT-29229. This came out of last year's discussion thread entitled "Packaging Application Metadata". Cheers, Mark
Re: javafxpackager and launcher
Comments inline… On Jan 10, 2014, at 12:11 PM, Danno Ferrin 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 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 us
Re: [8u] Code Review Request - RT-4169,[Stage] Setting 'icons' to null do not reset the Stage icon
If there are extra points, then Martin is going to get a whole pile of them for the oldest feature with RT-153 (alwaysOnTop). So what do you and he win? More bugs to fix? :) -- Kevin Stephen F Northover wrote: Hi Anthony, Please review https://javafx-jira.kenai.com/browse/RT-4169. It's an old one. Should there be extra points for fixing the oldest bug ever? Thanks, Steve
[8u] Code Review Request - RT-4169,[Stage] Setting 'icons' to null do not reset the Stage icon
Hi Anthony, Please review https://javafx-jira.kenai.com/browse/RT-4169. It's an old one. Should there be extra points for fixing the oldest bug ever? Thanks, Steve
RE: javafxpackager and launcher
Hi Danno, It's really great to see someone paying close attention to the packaging and deployment stuff, this level of effort has been sorely missed since Igor and Daniel left. Thanks for the contributions. John -Original Message- From: openjfx-dev-boun...@openjdk.java.net [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of Danno Ferrin Sent: Friday, January 10, 2014 9:11 AM To: Scott Palmer Cc: openjfx-dev@openjdk.java.net Subject: Re: javafxpackager and launcher 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 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/ja
hg: openjfx/8/master/rt: 4 new changesets
Changeset: 44acc56c806e Author:mv157916 Date: 2014-01-03 13:32 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/44acc56c806e RT-35171: Update the JDK 8 build number to b122 in rt/build.properties file in the JavaFX 8 Master forest. ! build.properties Changeset: 5aca75258738 Author:Rafi Tayar Date: 2014-01-06 11:23 +0200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/5aca75258738 RT-34744 [Touch, Lens] Scrolling is only possible using scroll bars Reviewed-by: dblaukop kcr jgiles ! buildSrc/armv6hf.gradle ! buildSrc/armv6sf.gradle ! buildSrc/x86egl.gradle ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ListViewSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TableViewSkinBase.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TreeViewSkin.java Changeset: 423cf238579d Author:Yves Joan Date: 2014-01-07 12:06 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/423cf238579d Sync up SceneBuilder changes ! apps/scenebuilder/SceneBuilderApp/src/com/oracle/javafx/scenebuilder/app/AppPlatform.java ! apps/scenebuilder/SceneBuilderApp/src/com/oracle/javafx/scenebuilder/app/SceneBuilderApp.java ! apps/scenebuilder/SceneBuilderApp/src/com/oracle/javafx/scenebuilder/app/SceneBuilderTest.java ! apps/scenebuilder/SceneBuilderApp/src/com/oracle/javafx/scenebuilder/app/ScenicViewStarter.java ! apps/scenebuilder/SceneBuilderApp/src/com/oracle/javafx/scenebuilder/app/i18n/SceneBuilderApp.properties ! apps/scenebuilder/SceneBuilderApp/src/com/oracle/javafx/scenebuilder/app/menubar/MenuBar.fxml ! apps/scenebuilder/SceneBuilderApp/src/com/oracle/javafx/scenebuilder/app/menubar/MenuBarController.java - apps/scenebuilder/SceneBuilderApp/src/com/oracle/javafx/scenebuilder/app/preferences/PreferencesDialogController.java - apps/scenebuilder/SceneBuilderApp/src/com/oracle/javafx/scenebuilder/app/preferences/SBPreferences.java ! apps/scenebuilder/SceneBuilderApp/src/com/oracle/javafx/scenebuilder/app/preview/PreviewWindowController.java ! apps/scenebuilder/SceneBuilderApp/src/com/oracle/javafx/scenebuilder/app/template/FxmlTemplates.java ! apps/scenebuilder/SceneBuilderKit/src/com/oracle/javafx/scenebuilder/kit/editor/EditorController.java ! apps/scenebuilder/SceneBuilderKit/src/com/oracle/javafx/scenebuilder/kit/editor/EditorPlatform.java ! apps/scenebuilder/SceneBuilderKit/src/com/oracle/javafx/scenebuilder/kit/editor/i18n/SceneBuilderKit.properties - apps/scenebuilder/SceneBuilderKit/src/com/oracle/javafx/scenebuilder/kit/editor/images/ImageUtilsBase.java ! apps/scenebuilder/SceneBuilderKit/src/com/oracle/javafx/scenebuilder/kit/editor/job/ModifyFxIdJob.java + apps/scenebuilder/SceneBuilderKit/src/com/oracle/javafx/scenebuilder/kit/editor/job/UsePredefinedSizeJob.java - apps/scenebuilder/SceneBuilderKit/src/com/oracle/javafx/scenebuilder/kit/editor/panel/content/gesture/mouse/ResizeShadow.java - apps/scenebuilder/SceneBuilderKit/src/com/oracle/javafx/scenebuilder/kit/editor/panel/hierarchy/ImageView.fxml ! apps/scenebuilder/SceneBuilderKit/src/com/oracle/javafx/scenebuilder/kit/editor/panel/hierarchy/treetableview/HierarchyTreeTableCell.java ! apps/scenebuilder/SceneBuilderKit/src/com/oracle/javafx/scenebuilder/kit/editor/panel/hierarchy/treeview/HierarchyTreeCell.java ! apps/scenebuilder/SceneBuilderKit/src/com/oracle/javafx/scenebuilder/kit/editor/panel/inspector/InspectorPanelController.java ! apps/scenebuilder/SceneBuilderKit/src/com/oracle/javafx/scenebuilder/kit/editor/panel/inspector/editors/AutoSuggestEditor.java ! apps/scenebuilder/SceneBuilderKit/src/com/oracle/javafx/scenebuilder/kit/editor/panel/inspector/editors/BoundedDoubleEditor.fxml ! apps/scenebuilder/SceneBuilderKit/src/com/oracle/javafx/scenebuilder/kit/editor/panel/inspector/editors/BoundedDoubleEditor.java + apps/scenebuilder/SceneBuilderKit/src/com/oracle/javafx/scenebuilder/kit/editor/panel/inspector/editors/ColumnResizePolicyEditor.java ! apps/scenebuilder/SceneBuilderKit/src/com/oracle/javafx/scenebuilder/kit/editor/panel/inspector/editors/CursorEditor.java ! apps/scenebuilder/SceneBuilderKit/src/com/oracle/javafx/scenebuilder/kit/editor/panel/inspector/editors/EditorUtils.java ! apps/scenebuilder/SceneBuilderKit/src/com/oracle/javafx/scenebuilder/kit/editor/panel/inspector/editors/EnumEditor.java ! apps/scenebuilder/SceneBuilderKit/src/com/oracle/javafx/scenebuilder/kit/editor/panel/inspector/editors/EventHandlerEditor.java ! apps/scenebuilder/SceneBuilderKit/src/com/oracle/javafx/scenebuilder/kit/editor/panel/inspector/editors/FxIdEditor.java ! apps/scenebuilder/SceneBuilderKit/src/com/oracle/javafx/scenebuilder/kit/editor/panel/inspector/editors/I18nStringEditor.java ! apps/scenebuilder/SceneBuilderKit/src/com/oracle/javafx/scenebuilder/kit/editor/panel/inspector/editors/PropertyEditor.java ! apps/scenebuilder/SceneBuilderKit/src/com/oracle/javafx/scenebuilder/kit/e
Re: javafxpackager and launcher
>> 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. I'd like to add the point that java (.exe) is simply a wrapper for libjli (jli.dll). In 7/8 the custom launcher uses this same interface to launch the application, so it technically already uses the same code to launch. The other features of the custom launcher *cannot* be replicated by the SE launcher without massive changes to JLI and the SE launcher code. Having said that... it's not entirely unreasonable to think that some useful parts of the launcher could be contributed to JLI. But that brings a host of other issues to the table, namely dealing with getting changes into OpenJDK and convincing the guys on the JDK tl team that such changes are necessary. By keeping the launcher code in fx packager, we keep the noise to a minimum which allows us to be able to be more flexible and responsive to developer demands. Once the product is mature enough, maybe we can revisit this. -DrD-
Re: javafxpackager and launcher
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 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 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 use
Re: Bug Pass Friday
Thanks David. I know this is painful but in the end we'll be in a better place. Steve On 2014-01-10 8:38 AM, David Grieve wrote: I'm going to take a pass at bugs assigned to Mick. https://javafx-jira.kenai.com/issues/?jql=project%20%3D%20RT%20AND%20issuetype%20%3D%20Bug%20AND%20resolution%20%3D%20Unresolved%20AND%20assignee%20%3D%20mickf If I get through that list, I'll start in on https://javafx-jira.kenai.com/issues/?jql=project%20%3D%20RT%20AND%20issuetype%20%3D%20Bug%20AND%20resolution%20%3D%20Unresolved%20AND%20assignee%20%3D%20paru These are just bugs, not tweaks or features. On Jan 7, 2014, at 4:27 PM, Stephen F Northover wrote: Hello Committers, I'd like to organize our work for 8u20 this week. Recall that 8u20 is about improving the quality of FX rather than implementing new features. https://wiki.openjdk.java.net/display/OpenJFX/8u20 Bug Owners: I suggest that we implement "Bug Pass Friday" where component owners and reviewers assess their bug backlog, clean up really old bugs that no longer apply and target the remaining bugs for either 8u20 or 9. In the case of bugs that don't have steps or sample code (and otherwise can't be reproduced), we should close them as 'Incomplete and ask nicely for more information: https://wiki.openjdk.java.net/display/OpenJFX/Submitting+a+Bug+Report Otherwise, please check the priority and adjust accordingly. Of course, crashes, exceptions and failed functionality tend to rate high. Component Owners: We have bugs that are unassigned or assigned to the wrong person. Component owners are asked to do a pass and ensure that all bugs that are assigned are assigned to owners or reviewers. Of course there will be exceptions and when in doubt, email the list or contact us and we will update the code ownership tables. https://wiki.openjdk.java.net/display/OpenJFX/Code+Ownership Unassigned bugs can stay that way or be assigned. It is likely that Kevin and I will do a pass on the unassigned bugs at a later time but if you know that a bug belongs to a certain person, assign it. This Tuesday is our first milestone and it will be uneventful because of the holidays. However, starting next week, we should have a good idea about the work that lies ahead and how much trouble we are in! Steve and Kevin
Re: Bug Pass Friday
I'm going to take a pass at bugs assigned to Mick. https://javafx-jira.kenai.com/issues/?jql=project%20%3D%20RT%20AND%20issuetype%20%3D%20Bug%20AND%20resolution%20%3D%20Unresolved%20AND%20assignee%20%3D%20mickf If I get through that list, I'll start in on https://javafx-jira.kenai.com/issues/?jql=project%20%3D%20RT%20AND%20issuetype%20%3D%20Bug%20AND%20resolution%20%3D%20Unresolved%20AND%20assignee%20%3D%20paru These are just bugs, not tweaks or features. On Jan 7, 2014, at 4:27 PM, Stephen F Northover wrote: > Hello Committers, > > I'd like to organize our work for 8u20 this week. Recall that 8u20 is about > improving the quality of FX rather than implementing new features. > >https://wiki.openjdk.java.net/display/OpenJFX/8u20 > > Bug Owners: > > I suggest that we implement "Bug Pass Friday" where component owners and > reviewers assess their bug backlog, clean up really old bugs that no longer > apply and target the remaining bugs for either 8u20 or 9. In the case of > bugs that don't have steps or sample code (and otherwise can't be > reproduced), we should close them as 'Incomplete and ask nicely for more > information: > > https://wiki.openjdk.java.net/display/OpenJFX/Submitting+a+Bug+Report > > Otherwise, please check the priority and adjust accordingly. Of course, > crashes, exceptions and failed functionality tend to rate high. > > Component Owners: > > We have bugs that are unassigned or assigned to the wrong person. Component > owners are asked to do a pass and ensure that all bugs that are assigned are > assigned to owners or reviewers. Of course there will be exceptions and when > in doubt, email the list or contact us and we will update the code ownership > tables. > >https://wiki.openjdk.java.net/display/OpenJFX/Code+Ownership > > Unassigned bugs can stay that way or be assigned. It is likely that Kevin > and I will do a pass on the unassigned bugs at a later time but if you know > that a bug belongs to a certain person, assign it. > > This Tuesday is our first milestone and it will be uneventful because of the > holidays. However, starting next week, we should have a good idea about the > work that lies ahead and how much trouble we are in! > > Steve and Kevin
