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.
Jasper noticed this issue, and I have verified it. It appears that the actual location to the JavaFX platform is stored in the project.properties file of each project. There are two fundamental problems with this: 1) The project is not portable to another machine with the default JavaFX SDK in a different location 2) You can't change the location of a particular JavaFX platform and have all projects that use that platform automatically pick it up (which may be the root cause of 202113) I would expect this to work like Java platforms, where only the name of the platform is stored in the project.properties file. The mapping of platform name to specific location on the machine should be in the user's .netbeans directory somewhere, right? Here is the e-mail from Jasper describing the bug. ----- I see a big issue with how the JavaFX SDK and Runtime locations are stored. It seem like you pick a platform with JavaFX support, at that point it stores the location of the JFX SDK and JFX Runtime inside the project properties file. The problem is that is a platform specific location. The result is a project created on Windows 64bit with 32bit Java can not be run on Mac, or Windows 32bit or Windows 64bit with 64bit Java without hand editing of project properties file. In project.properties for a project created on Windows 64bit with 32bit it contains: javafx.runtime=C:\\Program Files (x86)\\Oracle\\JavaFX Runtime 2.0 javafx.sdk=C:\\Program Files (x86)\\Oracle\\JavaFX 2.0 SDK In project.properties for a project created on Windows 64bit with 64bit it contains: javafx.runtime=C:\\Program Files\\Oracle\\JavaFX Runtime 2.0 javafx.sdk=C:\\Program Files\\Oracle\\JavaFX 2.0 SDK In project.properties for a project created on Mac it contains: ( which is specific to my machine as no standard location yet) javafx.runtime=/Volumes/Store/Projects/presidio/jfx/artifacts/sdk/rt javafx.sdk=/Volumes/Store/Projects/presidio/jfx/artifacts/sdk So a project created on one computer is not portable to another. As far as I understand NB handles this for JDK locations by storing them in private.properties not project.properties. This seems like a critical issue to me.
This bug is present in 201109202329
Will be fixed for FCS, not a Beta blocker so downgrading to P2.
*** Bug 203042 has been marked as a duplicate of this bug. ***
*** Bug 202677 has been marked as a duplicate of this bug. ***
*** Bug 202113 has been marked as a duplicate of this bug. ***
Fixed jet-main 47453b267ad2
Fixed in jet-main but the javafx properties are strange, the javafx project adds a non reference on endorsed cp, these cp entries depend on JFX layout which is forbidden.
fix extension to SDK paths: http://hg.netbeans.org/jet-main/rev/ac93e965eecc
added path reference validity check + warning if not http://hg.netbeans.org/jet-main/rev/9a97e865d8d6
Integrated into 'main-golden' Changeset: http://hg.netbeans.org/main-golden/rev/47453b267ad2 User: Tomas Zezula <tzezula@netbeans.org> Log: #202455:JavaFX platform must not be hard-coded in project.properties files
propagated the fix to all FX samples http://hg.netbeans.org/jet-main/rev/0dc87a0933c3
Integrated into 'main-golden' Changeset: http://hg.netbeans.org/main-golden/rev/0dc87a0933c3 User: Petr Somol <psomol@netbeans.org> Log: #202455 (follow-up): propagate the fix to all FX samples
verified in 7.1 FCS
Created attachment 130353 [details] project libraries
Is the bug really fixed? I attach a screenshot of "compile-time libraries" from a freshly created project in NB 7.2. Perhaps it works anyway, the "broken references" do. But it may look suspicious to the users.
even that IDE shows an absolute path anyway, projects.properties looks fine: javac.classpath=\ ${javafx.runtime}/lib/jfxrt.jar:\ ${javafx.runtime}/lib/deploy.jar:\ ${javafx.runtime}/lib/javaws.jar:\ ${javafx.runtime}/lib/plugin.jar