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.

Bug 202455 - JavaFX platform must not be hard-coded in project.properties files
Summary: JavaFX platform must not be hard-coded in project.properties files
Status: VERIFIED FIXED
Alias: None
Product: javafx
Classification: Unclassified
Component: Platform (show other bugs)
Version: 7.1
Hardware: PC Other
: P2 normal (vote)
Assignee: Tomas Zezula
URL:
Keywords:
: 202113 202677 203042 (view as bug list)
Depends on:
Blocks: 202113 202677
  Show dependency tree
 
Reported: 2011-09-21 20:34 UTC by kcr
Modified: 2013-01-18 10:20 UTC (History)
5 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
project libraries (6.98 KB, image/png)
2013-01-18 10:12 UTC, arataj
Details

Note You need to log in before you can comment on or make changes to this bug.
Description kcr 2011-09-21 20:34:04 UTC
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.
Comment 1 kcr 2011-09-21 20:38:56 UTC
This bug is present in 201109202329
Comment 2 John Jullion-ceccarelli 2011-09-21 20:56:31 UTC
Will be fixed for FCS, not a Beta blocker so downgrading to P2.
Comment 3 David Strupl 2011-10-07 13:51:45 UTC
*** Bug 203042 has been marked as a duplicate of this bug. ***
Comment 4 Anton Chechel 2011-11-07 09:37:47 UTC
*** Bug 202677 has been marked as a duplicate of this bug. ***
Comment 5 Anton Chechel 2011-11-10 13:53:51 UTC
*** Bug 202113 has been marked as a duplicate of this bug. ***
Comment 6 Tomas Zezula 2011-11-15 10:15:51 UTC
Fixed jet-main 47453b267ad2
Comment 7 Tomas Zezula 2011-11-15 10:19:11 UTC
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.
Comment 8 Petr Somol 2011-11-15 13:32:38 UTC
fix extension to SDK paths:
http://hg.netbeans.org/jet-main/rev/ac93e965eecc
Comment 9 Petr Somol 2011-11-15 15:24:16 UTC
added path reference validity check + warning if not
http://hg.netbeans.org/jet-main/rev/9a97e865d8d6
Comment 10 Quality Engineering 2011-11-16 15:48:46 UTC
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
Comment 11 Petr Somol 2011-11-16 18:23:10 UTC
propagated the fix to all FX samples
http://hg.netbeans.org/jet-main/rev/0dc87a0933c3
Comment 12 Quality Engineering 2011-11-17 07:28:35 UTC
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
Comment 13 Stepan Zebra 2011-12-06 16:00:48 UTC
verified in 7.1 FCS
Comment 14 arataj 2013-01-18 10:12:06 UTC
Created attachment 130353 [details]
project libraries
Comment 15 arataj 2013-01-18 10:15:44 UTC
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.
Comment 16 arataj 2013-01-18 10:20:42 UTC
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