This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Created attachment 129179 [details] MetronomeTransition NB project for the purpose of reproducing the issue I'm trying to drop-in an .ico file when using NB 7.3 beta to create a self-contained application. I'm placing the file subordinate to the project directory in the following directory: package\windows My NB project is named MetronomeTransition, and here is the location of the .ico file: some-directory-structure\MetronomeTransition\package\windows\MetronomeTransition.ico I selected the Enable Native Packaging checkbox in Project Properties | Build | Deployment, and invoked the Build Native Package menu option. The MetronomeTransition.ico isn't being picked up in the native installer (it uses the default icon). I've attached the NB project for the purpose of reproducing the issue. Also, please note the initial research that Petr Somol petr.somol@oracle.com did on this issue: Just reporting what I have found so far. The mechanism of adding icons through a dedicated subdirectory (package\windows\MetronomeTransition.ico) is AFAICT not the future stable way of doing it. As described at https://blogs.oracle.com/talkingjavadeployment/entry/packaging_improvements_in_jdk_7#7, from JDK7u10b8 the standard passing of icon to the deployment task should work. This is actually the same way as it was used before for passing icons to generate jnlp files etc. In NB there is support for this standard way of passing icons. In Project Properties -> Deployment you can fill a reference to your icon. This reference is then passed to <fx:deploy> as described in the document linked above. In other words, from JDK7u10b8 it just should start to work with the existing NB support. Nevertheless, I have not succeeded in making this work so far. One reason is a bug I discovered in how we store/pass the icon property inside NB, so I'll correct that soon. However, even if I corrected this problem manually, I could not succeed in creating a native package with custom icon for unknown reason - which seems to me to be on the JDK side. I tried it on JDK7u10b14. I always get a message like: "Using default package resource [application icon] (add package/windows/MetronomeTransition.ico to the class path to customize)" which does not make sense to me as the use of <fx:icon> should override the need to extend classpath. In NB we can not easily extend classpath for the VM in which Ant tasks run so this is not the path we could follow. Passing the classpath extension to Ant typedef when surfacing FX tasks does not seem to work either. Then it tells: "Icon File Name: C:\Users\psomol\AppData\Local\Temp\build8826762944645268846.fxbundler\windows\MetronomeTransition.ico" what shows that in windows the native packager creates a separate temporary directory for each run - the problem is that for each run a new temp dir is created with a different generated name, so the resources can not be substituted. I will investigate further and let you know if I get to something usable.
Using JDK1.7.0_09
(In reply to comment #1) > Using JDK1.7.0_09 On Dec 13, 2012, at 5:09 AM, PETR SOMOL <petr.somol@oracle.com> wrote: > Scott, > I have a problem with FX native packaging and have a question to ask - do I understand it right that I can ask you regarding FX deployment stuff ? Ultimately, Chris Bensen and Mark Howe will be picking up the packager, but I can answer this. > It is about the issue http://netbeans.org/bugzilla/show_bug.cgi?id=223626 which basically is about supplying custom icons to native packager and why it does not work from NB. I was told the issue is considered of high importance particularly on FX side - the first inquiry came from Jim Weaver but other people seem to be interested in it as well. > > To resolve the issue I rely on what is written at > > https://blogs.oracle.com/talkingjavadeployment/entry/packaging_improvements_in_jdk_7#7 Tucked away in that blog is a caveat that we only support the native platform icon type for each platform. So, a .ico only works for Windows and only an .icns will work on OS X. > So I decided to take a look into the FX packager code. Assuming that 7u10 actually contains FX 2.2.4, I cloned the following repo: > > http://jfxsrc.us.oracle.com/javafx/2.2.4/scrum/deploy/deploy/ > > The first question: is this the correct repository, corresponding to the just released 7u10 ? Yes, that's the deploy scrum, but it is in sync with the master repo. > so I checked DeployParams.getBundleParams() but here to my surprise a BundleParams object is constructed but no icon is passed to it from DeployParams, although BundleParams has provisions to pass icon info (setIcon()). > > Am I right that this is a mistake which causes the icon info to be ignored or do I understand something wrong ? This sounds like the right behavior given the current description. I will have to check to see if we support different icons for each platform we are trying to create a bundle for. Starting with one icon, or even one image file of any format and turning it into the proper icon for every platform is going to be a tall order. -- Scott
Thanks Petr. Sounds like we're blocked on this issue. @Joe, @Geertjan: Please advise whether I should file JavaFX and NetBeans issues for this, and if so, how to best file them so that the solution is coordinated between JavaFX packaging and NetBeans efforts. Please advise, Jim Weaver cc: adding Sharat Chander, Nicolas Lorain, Stephen Chin On 12/14/12 7:31 AM, PETR SOMOL wrote: > Jim, I have been in touch with Scott regarding more technical details related to this issue. I am forwarding my last explanation here to clarify more. > I just tried the 7u10 javafxpackager.exe and found that there was no command line argument listed in its help that would enable explicit specification of the icon file. This seems to be in line with my understanding, that it is the approach a) (see below) which is fully supported and working, but approach b) may have not been fully realized yet. > Petr > > > On 13.12.2012 17:49, PETR SOMOL wrote: >> Now I see my original description was misleading in more than one way. >> >> I understand there are now two official ways of passing an icon to native packager - a) by creating a resources/windows subdirectory and storing the icon into it before the call to the packager, and the newer option b) as described in the blog, i.e., by passing the icon as <fx:icon> element to <fx:deploy> task. So far only the first option has been successfully used by users and this is probably the way how Ensemble examples are realized. However, in NB the exact procedure required by approach a) does not work for reasons that I can explain if you were interested but which are not related to the issue I contacted you about. For the time being the only way we can implement for NB projects is the second approach b). >> >>>> so I checked DeployParams.getBundleParams() but here to my surprise a BundleParams object is constructed but no icon is passed to it from DeployParams, although BundleParams has provisions to pass icon info (setIcon()) >> >> And here is the second confusion I might have caused in my original description. I wrote there was provision to pass icon to Bundler, but in fact I meant just this: from the packager codes I could see that the icon reference is passed all the way through to DeployParams, but then it is ignored and forgotten when constructing BundleParams. So when BundleParams is later passed to the concrete Bundler implementation, there is no trace of any icon in it. By remarking that I saw "provisions to pass icon" I just meant that BundleParams is apparently meant to pass icon info because there exists a setter for that purpose in it, but it is never called. >> Petr >
Jim, thank you for recording our e-mail exchange here, I'll redirect all relevant details here as well. I keep investigating the issue and for now discovered the following discrepancy between JavaFX documentation and NB build system behavior. At http://docs.oracle.com/javafx/2/deployment/self-contained-packaging.htm I see the following sentence: "If you created a JavaFX project using Netbeans 7.2 or later, then the JavaFX Ant tasks are predefined, and "." is already added to the classpath by default." just under Example 6.5. This is not exactly true. In current NB build system we have provision to extend the <taskdef resource="com/sun/javafx/tools/ant/antlib.xml" ...> classpath, but we do not add "." by default. Currently this is to be done manually through project property endorsed.javafx.ant.classpath. If - for the purpose of native packager - "." should be added always, we can change the build script accordingly. Nevertheless, while trying to make the drop-in mechanism work I could not succeed with or without "." on taskdef classpath so far..
As we need the approach b) (see Comment #3) based on <fx:icon> to work correctly in FX SDKs ant-javafx.jar to make icon passing work in NB projects, I filed the following issue that needs to be resolved on FX side: http://javafx-jira.kenai.com/browse/RT-27029 Until the bug is confirmed and resolved, or explained to be invalid, we can not resolve the present NB issue. Nevertheless we will continue investigating whether at least a workaround can be found on NB side..
Observation regarding approach a), i.e., the drop-in mechanism: We did find a way to make drop-in mechanism work in NB, which unfortunately is not recommendable in general. Go to menu Tools->Options->Java->Ant and click Add Directory..., now add the path to your project here. From now on the native packager does recognize the drop-in resources and does use the custom icons. Surprisingly enough this works even without the '.' added to <taskdef> classpath attribute. The problem with this, and the reason why this is to be avoided, is the fact that it is a IDE-wide setting, not a project specific one. Thus, adding a project to Ant classpath in this way pollutes Ant classpath of the IDE as a whole. Moreover, when a project is transferred elsewhere, this setting is not.
I better file a waiver request for this issue with respect to 7.3 based on the following summary of the current state: Passing an icon to the JavaFX native bundler should be possible in two ways, according to FX documentation at http://docs.oracle.com/javafx/2/deployment/self-contained-packaging.htm#A1308687 and https://blogs.oracle.com/talkingjavadeployment/entry/packaging_improvements_in_jdk_7#7. a) the drop-in way relies on the <fx:deploy> Ant task from FX SDK to read the icon file from a relative subdirectory of a defined name. This mechanism currently does not work in NB due to the way NB handles Ant based build processes (Ant is not called from the project's root directory, etc.). Making changes in NB Ant-based build infrastructure would be quite dangerous this close before release because it would substantially affect virtually all Java based project types. The potential change would affect considerably an infrastructure that has worked reliably in principally unchanged state for many years. A workaround, though ugly, exists; see Comment #6. b) path to icon should be possible to pass to <fx:deploy> using a <fx:icon> definition. This approach is more in line with passing other types of information to the FX packager tasks and is actually already suppoted by NB. However, although it had been announced to work in JDK7u10 (FX SDK 2.2.4), it did not make it there. In JDK7u12 (FX SDK 2.2.6) improvements have been made but still the implementation fails to work on the FX SDK side. An issue has been filed in JavaFX jira: http://javafx-jira.kenai.com/browse/RT-27029 In the current state this NB issue #223626 depends on the state of external tooling that keeps evolving at fast rate. The bug in the external tools can be expected to be fixed in near future, what would either resolve this issue without the need of any action on our side or with possibly very little adjustment of the FX Application specific build scripts. Such adjustment then can be published as a patch. In the meantime a workaround (though ugly) can be applied. The waiver request does not mean for sure that the issue will remain open before NB7.3 branching; we just can not guarantee when the final solution date with respect to 7.3 branching date.
no comments on the waiver request since 20Dec, considering approved.
fixed in jetmain http://hg.netbeans.org/jet-main/rev/b90519c931ba I verified that <fx:icon> works with native packager since JDK7u14 (not before). the patch takes use of this. Also added improvements to enable separate handling of WebStart icon, native packager icon and splash image, and to convert between absolute and project-relative file paths, in case a local file is referenced.
Integrated into 'main-golden', will be available in build *201302070001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/b90519c931ba User: Petr Somol <psomol@netbeans.org> Log: #223626 - Drop-in icons not appearing in native bundle for self-contained JavaFX application
javafxpert, could you please verify that it works in Daily builds , so we can backport the fix into 7.3 Patch 1 ? Thanks in advance.
I tested on Mac and Windows, using JDK 7u17 and the latest development build of NB. It works for me on Mac but not on Windows. Mac: The icon (.icns file) that I selected in the Native Package Icon field of the Properties | Build | Deployment | Icon and Splash Image dialog was successfully used. Windows: The icon (.ico file) that I selected in the Native Package Icon field of the Properties | Build | Deployment | Icon and Splash Image dialog was not successfully used, rather, the default icon was used. Could someone please clarify the expected user steps on Windows? Note that I didn't alter the status of th issue. Thanks, Jim Weaver
I tried it today and confirm that on Windows it stopped working for unknows reason. Going to investigate..
Today I discovered the following problems in FX native packager (some of which had not been known to me before) that are all outside NetBeans: 1) At least on Windows the native packager expects the icon file to have the same name as is the name of the main project class. The patch presented in Comment #9 does not enforce this, so if users choose an icon with arbitrary name, it is simply ignored by the native packager. This particular problem can be overcome on NetBeans side by always creating a temporary icon copy, properly renamed, before passing to <fx:deploy> native packager task. This is now fixed in jetmain: http://hg.netbeans.org/jet-main/rev/bfc42e66d0f6 2) Surprisingly, the only JDK to support <fx:icon> correctly appears to be JDK7u14. I have today checked that JDK7u17 and JDK7u21 both fail silently, i.e., the native icon is silently ignored by their native packager. The patch in Comment #9 was made based on the assumption that once the correct behavior appeared once in 7u14, it will remain as part of all subsequent JDKs, but this turns out not to be true. Perhaps the newer JDKs are based on some pre-7u14 branch and serve as bugfixes only, while the fix in 7u14 has been forgotten to be transplanted ? I better summarize here how to verify that JDK7u14 does work (and the others do not): - install current NetBeans daily build - run it on JDK7u14 - create JavaFX Application project - in Project Properties dialog go to Deployment panel. Here edit "Icons and Splah image" and browse for a valid .ico file (on Windows). Close the icons' dialog by OK. Being again in the Deployment panel, check "Enable native packaging" and select All in the checkbox. (I assume you have all the necessary third party tools installed) - right-click project in Projects window and select "Build native package" - after a while (a couple of minutes) the build process finishes. Now check from outside NetBeans, that there is the dist/bundles/ sub-directory in the project dir and that it contains an .exe file having the correct icon. The fact that there is uncertainty as of which JDK versions do support <fx:icon> correctly, I recommend not to transplant the patches from this issue to 7.3 branch yet. I am marking this issue as candidate for the next patch, hoping that the situation on JDK side will have been clarified by then. At the same time I am going to reopen the jira issue RT-27029 with the same explanation as provided here. 3) <fx:deploy> task does not use native packager implementation from the same JDK, instead it uses the one from the running VM. This is a problem in NetBeans, where projects can use different Java platforms from the one on which NB itself (and its build process) runs. Therefore, support of <fx:icon> in the platform selected for project is irrelevant, instead the whole NB must be run on a platform that supports <fx:icon>. --------------- As there is apparently nothing more that can be done on NetBeans side regarding the inconsistent support of <fx:icon> in various JDKs, I am closing the issue again. When considering whether to leave the current support of native packager icons available to NB users, it is probably better to leave it so, because with some JDKs the functionality does work, and it can be expected that the bugs on JDK side will be resolved eventually.
Integrated into 'main-golden', will be available in build *201303132300* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/bfc42e66d0f6 User: Petr Somol <psomol@netbeans.org> Log: #223626 (followup) Drop-in icons not appearing in native bundle - added temporary icon renaming to compensate for packager restriction
*** Bug 228336 has been marked as a duplicate of this bug. ***
Adding icons as drop-in resources isn't currently supported (but possible with workaround) in NB environment (see Comment #7). Adding icons via Project Properties is working with recent JDK 8 builds, but still not working with current and next JDK 7 updates. Therefore, there will be no change for NB 7.3.1 -> removing patch target from whiteboard.