On 5/27/15, 12:08 PM, Scott Palmer wrote:
On May 27, 2015, at 10:04 AM, David Hill<david.h...@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 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.h...@oracle.com>
Java Embedded Development
"A man's feet should be planted in his country, but his eyes should survey the
world."
-- George Santayana (1863 - 1952)
