Cannot build the JavaFX Demos and Samples downloaded from:
The typical error (there are others) doing a Clean and Build is:
ant -f /home/ldasaro/javafx-samples-2.2.40/src/Ensemble jfx-rebuild
Target "jfx-rebuild" does not exist in the project "Ensemble".
Fails in under both Windows 8 and Ubuntu 12.04 operating systems.
Product Version: NetBeans IDE 7.4 RC1 (Build 201309112301)
Java: 1.7.0_40; Java HotSpot(TM) 64-Bit Server VM 24.0-b56
Runtime: Java(TM) SE Runtime Environment 1.7.0_40-b43
System: Linux version 3.2.0-53-generic running on amd64; UTF-8; en_US (nb)
System: Windows 8 version 6.2 running on x86; UTF-8; en_US (nb)
The biggest part of the problem is that the samples WONT initially build on JDK 7u40. They will build on 7u25, if I add the older platform and do a Clean and Build. But even then, they can be a bit finicky to get running. Once you get them to build and run on 7u25, then you can build them on 7u40. I'd feel sorry for a new guy that downloaded the latest JDK and NB and was struggling to build Oracle's Samples.
I don't know who "owns" responsibility for ensuring that Oracle's JavaFX Samples build and run, but it's not good when the "official" samples and demos don't build and run with the current tools and libraries.
See also https://javafx-jira.kenai.com/browse/RT-33065
Please see https://javafx-jira.kenai.com/browse/RT-33065 where it was listed as critical priority.
Ms. Masada pointed out to me that the JavaFX samples WILL NOT BUILD on NetBeans 7.4 using the default Java platform regardless of version. Won't build on JDK 7u25, 7u40 or 8.0 UNLESS you force a change to the Java platform (even if it's the same as the default Java platform) in project properties. Verified this is NOT an issue in 7.3 or 7.3.1
I suspect when the project is opened in 7.4, the code that executes opening/upgrading which causes the message "Default JavaFX Platform replaced by default Java Platform" may be deficient in some respect, and that forcing the platform change manually executes something that is ostensibly missing in the "opening/upgrading" code.
This anomaly occurs ONLY on NB 7.4 line. Tested using JDKs 7u25, 7u40 and 8.0 (in Netbeans.conf) with 7.4 RC1 and
Product Version: NetBeans IDE Dev (Build 201309240002)
Java: 1.7.0_25; Java HotSpot(TM) Client VM 23.25-b01
Runtime: Java(TM) SE Runtime Environment 1.7.0_25-b17
System: Windows 8 version 6.2 running on x86; Cp1252; en_US (nb)
(In reply to mr_lou_d from comment #3)
> Please see https://javafx-jira.kenai.com/browse/RT-33065 where it was listed
> as critical priority.
> Ms. Masada pointed out to me that the JavaFX samples WILL NOT BUILD on
> NetBeans 7.4 using the default Java platform regardless of version. Won't
> build on JDK 7u25, 7u40 or 8.0 UNLESS you force a change to the Java
I can build JavaFX samples on 7.4 RC1 build with 7u40 JDK w/o any problems, no changes in Java Platform needed.
Perhaps I am not making myself clear. With a freshly downloaded JavaFX sample project, using MB 7.4 RC1 on ANY JDK, Ensemble WILL NOT BUILD on the default Java platform. This has been repeatedly tested/documented and the anomaly was verified by the person responsible for JavaFX Samples at Oracle.
See the related JIRA at https://javafx-jira.kenai.com/browse/RT-33065
Please specify the environment where you were able to successfully build!
(In reply to Jiri Rechtacek from comment #4)
> (In reply to mr_lou_d from comment #3)
> > Please see https://javafx-jira.kenai.com/browse/RT-33065 where it was listed
> > as critical priority.
> > Ms. Masada pointed out to me that the JavaFX samples WILL NOT BUILD on
> > NetBeans 7.4 using the default Java platform regardless of version. Won't
> > build on JDK 7u25, 7u40 or 8.0 UNLESS you force a change to the Java
> I can build JavaFX samples on 7.4 RC1 build with 7u40 JDK w/o any problems,
> no changes in Java Platform needed.
Please see my other comment. The test case is:
Download the JavaFX Demos and Samples from:
Extract the Ensemble Project to some directory.
Start NetBeans 7.4 RC1.
Open the Ensemble Project.
Right-click on the Ensemble project and select "Build" from the pop-up menu.
For myself and others, the error message received is [ Target "jfx-rebuild" does not exist in the project "Ensemble" ]
As mr_lou_d has mentioned there is a issue with samples, because build-impl.xml and jfx-impl.xml build scripts have been changed and those in samples are not in a form (added/removed targets, properties...) that current NetBeans expects. They should be updated automatically, but in case of these samples it does not happen.
We need to investigate why (for example whether bundled build scripts in samples are not modified in a way that will prevent automatic update).
"I'd feel sorry for a new guy that downloaded the latest JDK and NB and was struggling to build Oracle's Samples."
I'm one such new guy and, boy, I am lost as heck. I want to get started with JavaFX, coming over from the C# WPF world, and I wanted a beefy sample like the Data App to get some real nice examples of different parts of a production-like system (most samples are tiny single class, so not very helpful.)
I just downloaded yesterday:
Product Version: NetBeans IDE 7.4 (Build 201310111528)
Java: 1.7.0_45; Java HotSpot(TM) 64-Bit Server VM 24.45-b08
Runtime: Java(TM) SE Runtime Environment 1.7.0_45-b18
I downloaded the samples, opened up the DataApp projects... and I get a couple of major issues almost right away:
ant -f C:\\java\\Samples\\DataApp\\DataAppClient jfx-rebuild
Target "jfx-rebuild" does not exist in the project "DataAppClient".
BUILD FAILED (total time: 0 seconds)
C:\java\Samples\DataApp\DataAppServer\nbproject\build-impl.xml:1469: The following error occurred while executing this line:
C:\java\Samples\DataApp\DataAppClient\nbproject\build-impl.xml:88: The J2SE Platform is not correctly set up.
Your active platform is: default_platform, but the corresponding property "platforms.default_platform.home" is not found in the project's properties files.
Either open the project in the IDE and setup the Platform with the same name or add it manually.
For example like this:
ant -Duser.properties.file=<path_to_property_file> jar (where you put the property "platforms.default_platform.home" in a .properties file)
or ant -Dplatforms.default_platform.home=<path_to_JDK_home> jar (where no properties file is used)
BUILD FAILED (total time: 0 seconds)
Some folks suggested (on other threads on forums) to add this to the build.xml:
But no dice.
Should I give up, roll back to some earlier version of JDK & Netbeans? Or is there some way out of this mess as is?
There is a workaround until this gets fixed:
Some projects downloaded from Oracle won't INITIALLY build using the default JDK, regardless of version, e.g. Ensemble. The workaround is as follows:
Use NetBeans Java Platform Manager (Tools->Java Platforms) and use "Add Platform" to create a new Java Platform named according to your default platform (in your case, JDK 7u45) pointing to the same JDK. Next, in your project, change Properties->Libraries->Java Platforms to use that newly named Java Platform. Then build the project - it should build successfully. Apparently, the act of changing the platform updates the project in some manner that allows it to be built. If you have multiple projects, change Properties->Libraries->Java Platforms for each of them. Sorry for the inconvenience.
Vote for the bug if you feel it's important to fix it.
Thanks, that did work for all the Samples except DataApp.
I ended up having to download and add the Jersey (?) library from https://jersey.java.net/download.html to get the DataAppClient to build. When I launched the server, it too complained about Classes not found from com.sun.jersey.spi. I found the jersey jar, downloaded added that...
Still got further messages about ASM missing, so I found that download, grabbed those, and now I'm stuck at "org.apache.catalina.LifecycleException: org.apache.catalina.LifecycleException: java.lang.IncompatibleClassChangeError: Implementing class"
Not a very auspicious start to my JavaFX exploration. =\ I'm equally confused as to why I'm running into all of these missing dependencies when they're not listed in the Readme's Dependencies section.
Is there a better, more functional sample or project out there that provides anything near the level of scope as the DataApp sample?
This is a non-trivial setup, and the bug you are up against is not THIS one (Bug 236120). At some point you may also run up against Bug 237181. I am unsure that this is a NetBeans bug at all, because the Sample JavaFX Projects downloaded from Oracle belong to the JavaFX folks who maintain those projects. If you find this is actually a NetBeans bug please open a NEW bug report on the NetBeans Bugzilla (JavaFX->Project). Make sure you report your Operating System in addition to NetBeans version, Java Platform, etc.
According to https://javafx-jira.kenai.com/browse/RT-30567 the DataApp sample was verified with Java 7u40, but with no indication as to what IDE/release was used.
Therefore, since I can't build the project either, I FILED A BUG on the JavaFX Jira. See https://javafx-jira.kenai.com/browse/RT-33722 - Suggest you click on "Watch Issue" and chime in with comments. Best regards.
It seems that genfiles.properties files in samples are somehow corrupted.
The easiest fix is to delete genfiles.properties file from all sample projects before the sample project is opened in the IDE (this file is located in nbproject directory of project). This will force the IDE to update all project-related files to the up-to-date versions.
Then there won't be any issues with building/running of the sample projects.
Roman, is this a task for the Oracle JavaFX team to edit/update the sample projects as you have described and then make them available for download from Oracle.com?
If so, I can either add to https://javafx-jira.kenai.com/browse/RT-33065
or will you contact Ms. Masada to that end? (Maybe both?)...
genfiles.properties file should be packed together with project, but it needs to be fixed. My recommendation is following:
FX team should remove genfiles.properties file from each sample, then open the project in NetBeans 7.2. This will cause that it will be possible to open sample projects in NetBeans 7.2 and newer. Then pack all updated projects into zip.
Then, if a project would be opened in newer NetBeans, all project files that need to be recreated/updated will be automatically processed during the first opening of the project in newer NetBeans and therefore the project will work in the current NetBeans.
Important thing is that there should not be manual mafifications of the project files like build-impl.xml and jfx-impl.xml. This has probably happened with FX samples and that led to the current state of genfiles.properties, which signalize the IDE that those are intentionally modified and should not be replaced by newer versions.
Sorry for the typo in the last paragraph. The first sentence in the last paragraph should be:
Important thing is that there should not be manual modifications of the project files like build-impl.xml and jfx-impl.xml.
Comment 20Alexander Kouznetsov
2013-12-03 00:29:28 UTC
Opening a project with deleted genfiles.properties file in NetBeans 7.2.1 doesn't recreate it. However it gets recreated with NetBeans 7.4. Looks like it is safe it just remove genfiles.properties files.
Why is it advised to keep them?
(In reply to Alexander Kouznetsov from comment #20)
> Opening a project with deleted genfiles.properties file in NetBeans 7.2.1
> doesn't recreate it. However it gets recreated with NetBeans 7.4. Looks like
> it is safe it just remove genfiles.properties files.
> Why is it advised to keep them?
One of the reasons why genfiles.properties should be kept (also in version control) is to prevent updating of these files, if they're manually modified. And this causes problems here with samples. It is also advised to put custom ant targets to build.xml, instead of build-impl.xml, but there is no guarantee that every user will do so.
I have tried NetBeans 7.2.1 and it worked without problems. I did following:
1. Unzipped samples
2. deleted genfiles.properties file from each sample
3. opened samples in NetBeans 7.2.1
4. Tried to run to verify whether everything is OK.
Note: earlier versions may not have notification about platform update.
But in this case of samples (and if above-mentioned method won't work for you) it is also acceptable, if you omit genfiles.properties in zip. This will cause that files that should be updated will be definitely updated to the required version (and genfiles.properties will be recreated, too).