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 217206 - Dependent JavaFX Application project gets rebuild each run and very often fails to do so because NetBeans holds the jar file
Summary: Dependent JavaFX Application project gets rebuild each run and very often fai...
Alias: None
Product: javafx
Classification: Unclassified
Component: Project (show other bugs)
Version: 7.2
Hardware: PC Windows 7
: P2 normal with 1 vote (vote)
Assignee: Petr Somol
Depends on: 213219
  Show dependency tree
Reported: 2012-08-22 09:52 UTC by Alexander Kouznetsov
Modified: 2012-09-21 02:28 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description Alexander Kouznetsov 2012-08-22 09:52:25 UTC
If you put one JavaFX Application project (A1) in Libraries section of another JavaFX Application project (A2) you can notice:
1. Each time you run A2, A1 gets re-built.
2. Very often it fails to be built because its dist/A1.jar file can't be deleted. Probably because NetBeans is holding it.

This is really annoying as it fails application run very often but also increases the time to build/run the app.
Comment 1 Petr Somol 2012-09-19 13:05:03 UTC
The use case described here I gather is the common situation when user needs to have a FX Application project dependent on library projects, that need to use FX features but that are not supposed to be run directly (only to serve as libraries for main runnable FX Projects). In other words, there should be a FX equivalent of the currently existing Java (SE) Class Library project. JavaFX Class Library unfortunately has not been provided yet but it is planned for near future with ever increasing priority, see Issue #213219.

The straightforward workaround (that is actually referred to in this issue) is to create a FX Application project and just use it as a library for another FX Application project. This, however, has several drawbacks.

As agreed with core FX team each run of a FX Application project is preceeded by full redeployment (creation of FX jar, html, jnlp artifacts from class files using tools from FX SDK). This considerably slows down each run if there is dependency on another FX project, which actually should not need any of this but in fact does it. On Windows systems the thus quite too frequent re-creation of deployment artifacts occasionally causes the irritating locking problem, which occurs when NetBeans releases the file lock for the created jar file but Windows file system reflects this with delay, leading to redeployment failures. This particular issue seems to be Windows specific.

The proper solution of this issue is to provide the JavaFX Class Library project, which would similarly to Java Class Library not be runnable, allowing for significantly more effective (re)build process. However, we will most likely not manage to do this for NB 7.3. But due to much demand this feature will be among the first realized in next NB release.

For the time being I suggest to use the following alternative workaround for the FX library use case:

For each intended FX library create the ordinary Java->Java Class Library project. In order to be able to use FX constructs in it, add manually the dependence on FX runtime as follows: in Projects panel, right-click the library project's Libraries node and choose Add JAR/Folder... Now find and select the jfxrt.jar file in the location of the FX runtime you are using. Now you can use FX in the library sources. Now add the dependence on your thus created "FX library" to the main FX Application project. The main FX Application project should build correctly, allowing the use of anything from the "FX libraries" as expected. Note that the build infrastructure is predisposed to this in the sense that jfxrt.jar is not copied to main project's dist/ subfolder although explicit reference (manually added) to it exists. The finally obtained deployment artifacts should be entirely correct.

This workaround effectively does what the not-yet-available JavaFX Class Library would. Build process with this workaround should be significantly faster.
Comment 2 Alexander Kouznetsov 2012-09-19 13:22:13 UTC
Thank you for the workaround. We actually are already using it. However, this is only a workaround, not a solution. What's the reason for this issue to be resolved as incomplete? 

There are at least two problems that are related to this issue:
- Sometimes both dependent projects need to be JavaFX applications. For example, one application is enhanced version of existing one.
- Managing links to correct jfxrt.jar files that match also JavaFX platform is not obvious enough and can lead to errors at runtime if jfxrt.jar versions mismatch between the projects.
Comment 3 Petr Somol 2012-09-20 15:32:46 UTC
I closed as incomplete based on the view that we need to redeploy at each run invocation according to an agreement with core FX team some time ago as I noted in Comment #1. In such case the only relevant improvement achievable would be the FX Library project which is out of scope for NB 7.3.

However, yesterday and today I tried to investigate more about when do we need to redeploy and for for purpose. As a result I found out that there might be room for improvement (i.e., I do not see the reasons for the forced redeployment to be valid any more). The following changeset:

makes the deployment step of build process conditional similarly to the build process itself. In case no change has been made in source files, repeated runs should now bypass the deployment step once it has been accomplished. This should work well also in case of dependencies among projects. I verified that making a change in dependent project is recognized and causes redeployment; otherwise redeployment is bypassed.

I tried to reproduce the locking problem but could not reproduce it now (I have seen it in the past but rarely).

This I believe fixes this issue so I am closing it. If you find a problem with the new build mechanism apparently related to this change, please reopen. If you find a file lock problem, please create another issue for it as it is technically unrelated to the build mechanism that I just changed.
Comment 4 Quality Engineering 2012-09-21 02:28:48 UTC
Integrated into 'main-golden', will be available in build *201209210001* on (upload may still be in progress)
User: Petr Somol <>
Log: #217206 - Dependent JavaFX Application project gets rebuild each run