JavaFX application packaging & deployment with dependent libraries

John Smith John_Smith at
Wed Apr 3 13:15:06 PDT 2013

I understand that you don't want to hack the NetBeans build directly for this, however, the quickest solution might be to:

replace the following line in your <projectdir>/nbproject/jfx-impl.xml file:
            <property name="pp_jar_fs2" value="lib${file.separator}*.jar"/>
            <property name="pp_jar_fs2" value="{file.separator}*.jar"/>

The above solution would be fragile in that a NetBeans version upgrade would likely overwrite your hack (also I haven't tried it myself so you might need to make a few more build script hacks to get everything working).


The defaulting of the lib/ prefix to the dependent classpaths would seem to be a NetBeans implementation specific thing, so if you wish more flexibility there, you should file an issue against the NetBeans project:


In the build.xml file for your project which has been automatically generated by NetBeans, there is documentation for user added callback stubs for the netbeans build process (-post-jfx-jar: and -post-jfx-deploy:), possibly by providing these callback stubs in the build.xml, you could post manipulate the manifest in the created jar file to achieve the settings you require.  Because you will be making use of documented user supplied callbacks, NetBeans should continue to support whatever you put in there going forward so that your project won't break if NetBeans generates new project build files (as it seems to do with every NetBeans version upgrade).


The solutions below are significantly more work, so you may not wish to undertake them.

I believe that if you just use the standard JavaFX packaging tools which come with JavaFX rather than using the NetBeans autogenerated build project files, you will be able to get the flexibility you want as I don't think these tools default a lib/ directory prefix for dependent jars.

You can use either the JavaFX Ant Tasks:
Or the javafxpackager tool:

There is also a JavaFX maven and gradle plugins you could try to see if they package how you want (if you are open to using a different build system):

Some advantages of the alternate tools approaches are that your build is not NetBeans specific, your build won't be broken by a NetBeans version upgrade and your build can be used easily in other contexts (though you do lose a lot of the simplicity of auto-generating build scripts just by clicking GUI options).

-----Original Message-----
From: openjfx-dev-bounces at [mailto:openjfx-dev-bounces at] On Behalf Of Sergey Troshin
Sent: Wednesday, April 03, 2013 3:02 AM
To: openjfx-dev at
Subject: JavaFX application packaging & deployment with dependent libraries

Hi all,

I have one question on the packaging of a JavaFX application dependent on additional user libraries.

My project consists of the command-line tool designed as the standalone JAR package (tool.jar), and of the UI tool created as the JavaFX application (tool-ui.jar). The UI tool uses the command-line tool JAR as the library, and on its own implements the FX application classes and related UI elements. The project wizard of NetBeans 7.3 created for me the FX project with a number of XMLs. When I instruct NetBeans to use tool.jar as the required library for the FX application, it copies the JAR to dist/lib/tool.jar during the build and hard-codes the property
"JavaFX-Class-Path: lib/tool.jar" to  the FX MANIFEST of ui-tool.jar. 
That's the problem for me, since I want to make the both tools to be available to the users in the same binary directory, like this


It should be possible for my users to use either standalone tool.jar, or to use them both over ui-tool.jar launching. However, ui-tool.jar is hard-coded to depend on lib/tool.jar, that cannot be changed anyway over NetBeans. Surely, I can patch/hack the project XMLs files with build rules and targets generated by NB. However, they are pretty messy and complex, can be regenerated by NB anytime. Moreover, seems they do use a service code from the JDK.

Placing my JARs as described above leads to ClassNotFoundException when trying to start `java -jar ui-tool.jar', because lib/tools.jar doesn't exist. The workaround is to start the UI tool like this `java -classpath tool.jar:ui-tool.jar com/javafx/main/Main'. That works, but I would prefer to control the generated JavaFX-Class-Path property, or to change the path for dependent libraries in NB. I've seen in NB project the settings "Libraries/Library Folder". It doesn't work for me in the wanted way - just points to the directory where to get the library, but embeds the same property value to the MANIFEST as before.

Please kindly advise how can I deal with this issue,

Thank you,
Sergey Troshin

More information about the openjfx-dev mailing list