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.
|Summary:||JavaFX Application Project fails to run or debug when dependent on another javafx project|
|Component:||Project||Assignee:||Petr Somol <psomol>|
|Issue Type:||DEFECT||Exception Reporter:|
|Bug Depends on:||213219|
Description sldr 2012-05-30 00:15:19 UTC
The simple solution is to create a "JavaFX Library Project". To reproduce the problem do the following: * Create a JavaFX Application project named p1 (you can use any name). Make sure Create Application Class is checked and a valid name entered. You should be able to run the project and it should work fine. * Create a JavaFX Application project named p2. Make sure Create Application Class is NOT checked. * Create a java class in project p2 (the class can be empty, you need at least 1 java file for the project to build). Build project p2 (it should build fine). * Edit the project p1 properties and on the libraries catagory click the Add Project... button to add project p2 as a library to p1 (this should be in the Compile tab btw). Now when you run (or debug) p1 it fails with an "Unable to find application class name" error. What seems to be the problem (I didn't dig the whole way into it so I could be wrong here) is that the JavaFX Packager is being feed the wrong information from ant. The following error during run (or debug) is the clue: Duplicated project name in import. Project jfx-impl defined first in C:\Users\me\Documents\NetBeansProjects\p1\nbproject\jfx-impl.xml and again in C:\Users\me\Documents\NetBeansProjects\p2\nbproject\jfx-impl.xml Already defined in main or a previous import, ignore -init-debug-args Workarounds: * Edit the p1 project properties again. This time go to the Run catagory and enter the following in the VM Options field (you can leave off "-Djavafx.verbose=true" and "-Djavafx.preloader.class=p3.P3Preloader" for this example): -Djavafx.verbose=true -Djavafx.application.class=p1.P1 -Djavafx.preloader.class=p3.P3Preloader * When creating p2 create it as a JavaFX Preloader project. Make sure Create Preloader Class is checked (otherwise it won't let you create the project (so why is it a checkbox if I have to check it and enter a valid name??? (I guess I have to do another bug report... :-) ))) and enter a valid name. When the project is created gut the preloader class by removing extends Preloader and deleting the class internals (or just delete the class entirely). Now add whatever JavaFX code you want. Don't forget to make project p1 depend on project p2.
Comment 1 Petr Somol 2012-05-30 08:18:57 UTC
Thanks for finding this out. Actually I see the problem relates to the build/deployment process that takes place in FX Applications; the existence of Application class is assumed when calling FX SDK deployment tasks. It seems we will need a JavaFX Class Library project type as counterpart of Java Class Library to make things straightforward. I created a separate issue for that: issue 213219. As for "Duplicated project name in import" - this is not the reason of the problem. See issue 208484.
Comment 2 Stepan Zebra 2012-05-30 11:49:27 UTC
It works for me in the latest Dev build. In project.properties, there is a different order of targets in run.classpath, comparing to 7.2 Beta and earlier...
Comment 3 Petr Somol 2012-05-30 15:22:36 UTC
(In reply to comment #2) > It works for me in the latest Dev build. In project.properties, there is a > different order of targets in run.classpath, comparing to 7.2 Beta and > earlier... I have tried to create a FX Application with unchecked "create application class" in the creation wizard to serve as library, then made a dependence on it from another FX Application and I can confirm this works in the current daily build. This is due to recent fixes of other indirectly related issues after 7.2beta. Thus I am closing this particular issue, but I am leaving the JavaFX Class Library task (issue 213219) open because proper JavaFX library support would be better for at least the following reasons: a FX Application serving as a library fails ungracefully when attempted to run directly, during build process it creates invalid deployment artifacts as if it was a launchable application although this is not the case, dedicated JavaFX Class Library type would be more intuitive as of its purpose.
Comment 4 sldr 2012-05-30 16:15:14 UTC
Thanks for quick response. I am looking forward to 7.2...