I might be mistaken, but it would seem you are trying to build or run a preloader project. That won't work!

In order to run your "main" project with a preloader, right-click the "main" project, select "Properties" and click on the "Run" category. Here you will click the check box for "Use Preloader:", then click the "Browse..." button. This will allow you to choose the Preloader to use for this project.

Please let us know if this solved the problem with the Preloader projects.

Regarding "Existing JavaFX Application projects do not compile, too.", please provide more detail! Be advised that since JavaFX is now contained within the JDK, references to "Default JavaFX Platform" may need to be updated in Project Properties->Libraries to reflect the default Java Platform JDK in the event that this did not happen automatically.

Additionally, if you have a complex project similar to Ensemble, and are experiencing Bug 236120 - The work-around in that case is to create a named Java Platform in Project Properties->Libraries->Manage Platform, and change the Java Platform to point to it. The project should now compile and run.

Please let us know if this solved the general build problems.

Just to make sure, I built and tested JavaFX project with preloader. Swapped out preloader for a different one and built and tested successfully. Built and successfully tested Ensemble project using Bug 236120 work-around. Used JDKs 7u17 and 7u40 to build. Test environment:
Product Version: NetBeans IDE Dev (Build 201310160001)
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-54-generic running on amd64; UTF-8;(Ubuntu 12.04)

@ "I might be mistaken, but it would seem you are trying to build or run a preloader project. That won't work!"

Ah, OK! Then I missed a detail - but: In terms of usability, wouldn't it be more consistent if a preloader project could be compiled and built like any other Java application/library project or JavaFX project? Even trivial preloaders contain code and the developer wants to know whether code compiles or not. It feels very awkward if there is java code in a project that itself does not depend on other projects (especially not on the javafx application project!) - and I cannot compile that code independently from other projects. 
Moreover, if I didn't get the IDE wrong, you should be able to add a preloader JAR(!) to a JavaFX application. How do I get a preloader JAR, if the IDE refuses to compile and build a JAR from a preloader project?

IMO this should be regarded as a usability issue. This seems to be inconsistent behaviour and not sufficient for a simple and flexible (re-)use of preloaders in JavaFX applications.

I think, there even should be a way to preview preloaders or launch them independent from an application - be it just for testing. But that might be more of a JavaFX platform topic, not an IDE issue.

(In reply to mr_lou_d from comment #2)
> Just to make sure, I built and tested JavaFX project with preloader. Swapped
> out preloader for a different one and built and tested successfully. Built
> and successfully tested Ensemble project using Bug 236120 work-around. Used
> JDKs 7u17 and 7u40 to build. Test environment:
> Product Version: NetBeans IDE Dev (Build 201310160001)
> 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-54-generic running on amd64; UTF-8;(Ubuntu 12.04)

I tried that too, it worked on openSuSE. Using new projects, created with the NB7.4 templates seemed to be OK. After this, tried again with the NB7.3 projects, on windows. There I hat also issues with the default JDK, de- and re-installed jdk 1.7u40 and jdk 1.8, and here I have a very strange situation.


At first, I hat compiler issues, because jdk1.8 was recognized as default platform, and (I think due to Win7 problems with JAVA_HOME), I set the target platform to 1.7 but some code anyway got compiled for jdk1.8. At least the errors suggested that: the projects compiled, the application got built, but when startet, it stalled with a major.minor version fault, saying it saw jdk1.8 class binaries. 

Then, I changed the netbeans_jdkhome to jdk1.7u40, and tried again to run the application from within the IDE - it worked, the application got built and started with preloader.

After this, I added a new JAR to the project (ScenicView), and then something strange happened: The preloader JAR vanished from the libraries list, and the application didn't compile any more. At first it seemed like the compiler could not resolve *any class from any referenced project* any more. I added the preloader JAR to the project libraries again, and then at least classes from all other referenced projects got resolved. But not the classes from the preloader JAR. 
And that seems to be the original problem again: when compiling the application, the preloader jar or project is not recognized. All in all very strange.

(In reply to mr_lou_d from comment #2)

> 
> Regarding "Existing JavaFX Application projects do not compile, too.",
> please provide more detail! Be advised that since JavaFX is now contained
> within the JDK, references to "Default JavaFX Platform" may need to be
> updated in Project Properties->Libraries to reflect the default Java
> Platform JDK in the event that this did not happen automatically.
> 
> Additionally, if you have a complex project similar to Ensemble, and are
> experiencing Bug 236120 - The work-around in that case is to create a named
> Java Platform in Project Properties->Libraries->Manage Platform, and change
> the Java Platform to point to it. The project should now compile and run.
> 
> Please let us know if this solved the general build problems.

I need to investigate deeper, but so far, it didn't solve the problem. Also, it seems like there happened another strange thing after altering netbeans_jdkhome from jdk1.8 to jdk 1.7: in the platforms list now Default is jdk1.7, but jdk8 is not listed anymore. Instead, I now have another entry for jdk1.7 - that is just the same like the Default JDK. I never registered jdk1.7 as a new Platform.

Where (in which config file) does the IDE manage the platform definitions?
Does it make sense to have a look and eventually edit them manually?

(In reply to mr_lou_d from comment #1)
> I might be mistaken, but it would seem you are trying to build or run a
> preloader project. That won't work!
> 
> In order to run your "main" project with a preloader, right-click the "main"
> project, select "Properties" and click on the "Run" category. Here you will
> click the check box for "Use Preloader:", then click the "Browse..." button.
> This will allow you to choose the Preloader to use for this project.
> 
> Please let us know if this solved the problem with the Preloader projects.
> 
> Regarding "Existing JavaFX Application projects do not compile, too.",
> please provide more detail! Be advised that since JavaFX is now contained
> within the JDK, references to "Default JavaFX Platform" may need to be
> updated in Project Properties->Libraries to reflect the default Java
> Platform JDK in the event that this did not happen automatically.
> 
> Additionally, if you have a complex project similar to Ensemble, and are
> experiencing Bug 236120 - The work-around in that case is to create a named
> Java Platform in Project Properties->Libraries->Manage Platform, and change
> the Java Platform to point to it. The project should now compile and run.
> 
> Please let us know if this solved the general build problems.

Strange, too: When compiling the application, I get a message like this: 

R:\MyProject\src\myapp\fxclient\Main.java:25: error: package mypreloader.preloader does not exist
import mypreloader.preloader.PreloaderMessageNotification;

But in the IDEs project tree, the Main class does not have the red tick overlay that should signal compilation errors or problems in the code of that class.

(In reply to mr_lou_d from comment #1)
> 
> Additionally, if you have a complex project similar to Ensemble, and are
> experiencing Bug 236120 - The work-around in that case is to create a named
> Java Platform in Project Properties->Libraries->Manage Platform, and change
> the Java Platform to point to it. The project should now compile and run.
> 
> Please let us know if this solved the general build problems.

I created a new Platform entry for the jdk1.7u40, but the problem is exactly the same. 
It did not seem to have any visible effect.

An idea what might be the reason for the compiler error:

- The application should get built, and it depends on the preloader
- (at least when using Clean and Build), all previously built jars get deleted
- ... and next, the compiler seems first go through the app soure code,
      and that needs to import classes from the preloader binary, 
      and there is no preloader binary any more!
      :-(
- And, without beeing able to build a jar from a preloader project, 
  there is no chance to work around this. The preloader binary is gone. 
  Seems like I have to build from console to get around this.

Anyway, what is the rationale for not beeing able to compile and build a preloader project independent from a JavaFX application project?

Why does a preloader need an application class for getting compiled?

When I compile and package the preloader project manually from console, the IDE does not recognize a Preloader class in the JAR file. 

Further on, it seems like the IDE does not close a once selected Preloader JAR file even, if you choose another one afterwards: The windows explorer refuses to delete the JAR file, because it is still kept open by the Netbeans IDE (so it says).

So, at last there seems to be a workaround for the more complex scenarios as described in http://docs.oracle.com/javafx/2/deployment/preloaders.htm#BABGGDJG

1. javac the preloader project, by ant or from the console

   DO NOT USE javavfxpackager -createjar, it asks for an application class
   (BTW: it seems like the IDE tries exactly this - does it?)

2. Add a manifest, in the required fashion

3. build the jar

4. add the jar to the project dependencies

5. select your preloader.jar as the applications preloader source

6. add the preloader class to the VM options 
  (necessary since the IDE does not recognize it): 
   -Djavafx.preloader.class=mypreloader.preloader.Preloader

Simple scenarios like the standard templates may work, but at present we cannot use the IDE for the advanced preloader scenarios as intended by the JavaFX API (see above). Please take care of this - it really hurts.

(In reply to rrohm from comment #9)
 
> Why does a preloader need an application class for getting compiled?

It doesn't. You can right-click on the "YourPreloader.java" file and select compile. But you can't run it, since it doesn't have a main or Application class.

> Anyway, what is the rationale for not beeing able to compile and build a
> preloader project independent from a JavaFX application project?

I don't know, and I agree with you! I would request an Enhancement that provides the capability of building a Preloader project into a Jar from the IDE. You still can't run or debug it, but at least you could build the jar separately. It makes sense, particularly in a large project where you just want to tweak the preloader and make sure it builds without having to build the main project. I don't know the downside of implementing this, perhaps ROMAN does.

HOWEVER, as far as I can tell, this bug report is NOT a product DEFECT. Rather, you are dissatisfied with the implementation of Preloader projects in NetBeans as described in http://docs.oracle.com/javafx/2/deployment/preloaders.htm#BABBCGAE

If I am wrong, my apologies, and please describe the specific defect so that it may be fixed. Otherwise, will update Issue Type to Enhancement.

ALSO, this really isn't a P1 priority, as there are viable (although annoying) workarounds, making it a P3 according to priority guidelines at wiki.netbeans.org/BugPriorityGuidelines
as opposed to P2 usability, which is defined as "Prevents users from completing work without significant or inefficient legwork".

(In reply to mr_lou_d from comment #12)
> (In reply to rrohm from comment #9)
>  
> > Why does a preloader need an application class for getting compiled?
> 
> It doesn't. You can right-click on the "YourPreloader.java" file and select
> compile. But you can't run it, since it doesn't have a main or Application
> class.
Hm, OK. That's better than nothing, but does not solve the build issue - and without beeing able to build you won't get an app with dependencies to a preloader to compile and build.
> 
> > Anyway, what is the rationale for not beeing able to compile and build a
> > preloader project independent from a JavaFX application project?
> 
> I don't know, and I agree with you! I would request an Enhancement that
> provides the capability of building a Preloader project into a Jar from the
> IDE. You still can't run or debug it, but at least you could build the jar
> separately. It makes sense, particularly in a large project where you just
> want to tweak the preloader and make sure it builds without having to build
> the main project. I don't know the downside of implementing this, perhaps
> ROMAN does.
> 
> HOWEVER, as far as I can tell, this bug report is NOT a product DEFECT.
> Rather, you are dissatisfied with the implementation of Preloader projects
> in NetBeans as described in
> http://docs.oracle.com/javafx/2/deployment/preloaders.htm#BABBCGAE
> 
> If I am wrong, my apologies, and please describe the specific defect so that
> it may be fixed. Otherwise, will update Issue Type to Enhancement.

Well, I only can tell from the perspective of a NetBeans User/JavaFX developer.
From this perspecive, I would say: the JavaFX API provides the feature of 
andvanced preloaders, e.g. for displaying app initialization progress - so,
if NetBeans supports JavaFX + Preloaders, it should support the whole thing.
Not only the simple use case. So far, it would indeed be more of an enhancement.
But effectively, this breaks the ability to compile and build the app. Thus, 
IMHO it is not a necessary enhancement but a sort of conceptual flaw: A required enhancement would *enhance* the existing software, but without that 
enhancement, the software should not be degraded compared to the previous version. 
In this case, we in fact have a regression - in NB 7.3 I could develop
and build the projects, in NB 7.4 I cannot any more, rendering the new version useless for a project that startet with the previous version unless there is a workaround. 
IMO, that's definitely not a case for an enhancement, that should be regarded as a defect.
 
> ALSO, this really isn't a P1 priority, as there are viable (although
> annoying) workarounds, making it a P3 according to priority guidelines at
> wiki.netbeans.org/BugPriorityGuidelines

That's right - sorry, I forgot about changing P1 before/after the last comment. 

> as opposed to P2 usability, which is defined as "Prevents users from
> completing work without significant or inefficient legwork".

Well, as long as you do not have to work on the Preloader, a P3 might be OK.
But when it comes to working on the Preloader, it (IMO) quickly becomes 
just (or only a little bit more than) plain "legwork". 
I think, that could be argued from different views, but I would not insist on a P3. What about a P2.5 ;-)

Should be: 
... but I would not insist on a *P2*. What about a P2.5 ;-)

ROMAN: The ability to BUILD a preloader project into a jar (which you can then use as the preloader from your main project(s)), was (inadvertently ?) deprecated in NetBeans 7.4. Because this functionality was available in NetBeans 7.3.1, this seems a valid defect now (appears to have passed Sanity testing back in August).
Because reporter stated this is not a P1, changing to P2.

Thanks for report, now it should be able to build the FX Preloader project directly.

fixed in jet-main:
http://hg.netbeans.org/jet-main/rev/adf9f7c136a6

ROMAN: Thank you! Can you add this as a 74patch1-candidate? Or to whom should I make this request?

verified in trunk

Transplanted into release74 branch:
http://hg.netbeans.org/releases/rev/8b0efadf153e

Verified Fixed in NetBeans 7.4-patch1