Building Scene Builder

David Hill David.Hill at
Wed May 27 16:47:24 UTC 2015

On 5/27/15, 12:08 PM, Scott Palmer wrote:
>> On May 27, 2015, at 10:04 AM, David Hill<David.Hill at>  wrote:
>> On 5/24/15, 10:56 AM, Scott Palmer wrote:
>>> Where can I find the instructions for building Scene Builder from source?
>>> I ran Ant in the apps/scenebuilder folder and it produced
>>> SceneBuilderApp.jar in the 'SceneBuilderApp/dist' folder.  But where's the
>>> rest of it?  It looks like the javapackager part does run automatically, so
>>> I don't have a native executable with a nice icon and all those finishing
>>> touches that make it a "real" app.
>> I am in the process of adding a "run" command to the ant script. We do not have plans at the moment to add a packaging step.
> What happened to the original packaging step?  The Oracle download is a packaged app, was it a manual step or something?  I can’t even find the application icon in the source.
Our internal build has 2 parts - OpenJFX and the "closed" stuff. The "closed" stuff has a lot of legacy steps that we have not had the time or inclination to move to the OpenJFX side. (after all, working with a complex chunk of delicate gradle/ant code for a long time tends to make your eyes bleed).

But occasionally we get some motivation and we move another bit of functionality over. I did ask our packager guy if he could sketch out how to do this standalone, so it might happen.
>>> I did notice the build output print a "jfx-deployment:" step, but I guess
>>> that is something else. I haven't used Ant in years, so I'm a little
>>> rusty.  I was actually surprised that there wasn't a Gradle script in the
>>> apps/SceneBuilder folder.  I thought perhaps the apps are just using the
>>> default NetBeans project format.  I then noticed when loading the project
>>> in NetBeans that I didn't get the little "FX" decal on the coffee cup icon,
>>> so it isn't a NetBean "JavaFX" project.
>> When I added in the building of the apps in the overall tree, I was constrained by several things that gradle does not (or did not) play nicely with.
>> We wanted to treat most of the items as independent sub projects, and at least some of them have ant scripts that needed to be included in the samples bundles.
>> To shorten the story, after a long while of tinkering, I found that for our purposes, ant worked better for us. Gradle imports the ant projects, and allows us to call into them.
> Fair enough, there’s only so much tinkering one can take, I’ve been through a fair bit of Gradle tinkering myself.
> (My hope is that one day OpenJDK + OpenJFX will build simply with ‘grade build', using Gradle’s support for native builds.  Especially on Windows where it would simplify things a lot if you can avoid dependencies on Cygwin or MinGW.  Gradle’s native support is still incubating so it is a bit early to go there, but I’ve used it recently for some Java +JNI projects on Linux, Mac, and Windows (with Visual Studio, not GCC) and it actually worked quite well.)
We switched to gradle early on after a long time with a big pile'o ant scripts. Major rework for that. We were limited by the gradle versions we could get at the time. Some choices like what we could do in the apps dir were limited by that. More major rework when we moved as much as we could to OpenJFX. Now, if we had a dedicated build engineer we might be able to rebuild our current gradle to use the new features. But as we only have part time on about 3 guys willing to dive into that build mess that each have a huge pile 'o bugs... :-)

David Hill<David.Hill at>
Java Embedded Development

"A man's feet should be planted in his country, but his eyes should survey the world."
-- George Santayana (1863 - 1952)

More information about the openjfx-dev mailing list