Building Scene Builder

[Scott Palmer]

> On May 27, 2015, at 12:47 PM, David Hill <David.Hill at oracle.com> wrote:
> 
> On 5/27/15, 12:08 PM, Scott Palmer wrote:
>>> On May 27, 2015, at 10:04 AM, David Hill<David.Hill at Oracle.com>  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 suspect the main issue will be in the handling of Oracle’s signing certificate, which I suspect is part of the application bundle.  So the OpenJFX build will need to get the signing info from a config file or generate a self-signed certificate.
That’s assuming the icon and other packaging info can be “moved over” without having to get too many lawyers involved.

>>>> 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... :-)

Yeah, obviously bug fixes get priority… I’ve filed nearly 200 of them, so I have a stake there too :-)

But as Sven pointed out, someone in the open source community might be inclined to ease their build pains with some tweaks to the scripts.  The main problem with that is keeping compatibility with the “closed” parts.  Obviously while we are hacking on OpenJFX we can’t tell what our changes might be breaking for the closed portion.

Scott