Building Scene Builder

[Jonathan Giles]

I should note that on my main development machine I build openjfx using the latest gradle release - 2.4 I think. As far as I can see there are no issues with this.

-- Jonathan
Sent from a touch device. Please excuse my brevity.

On 28 May 2015 05:21:49 GMT+12:00, Kevin Rushforth <kevin.rushforth at oracle.com> wrote:
>
>
>Sven Reimers wrote:
>> So,  is this a call for community and Gradle experts please helps us?
>>
>> We are able (and want) to upgrade to a newer gradle version?
>>   
>
>Not for FX 8u. We will upgrade FX 9 to a newer gradle (e.g., .2.3 or 
>later). See:
>
>https://javafx-jira.kenai.com/browse/RT-40256
>
>-- Kevin
>
>> We want to share the whole pile of dirty gradle scripts to get you
>started?
>>
>> Sounds interesting to me...
>>
>> -Sven
>> Am 27.05.2015 18:48 schrieb "David Hill" <David.Hill at oracle.com>:
>>
>>   
>>> 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 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 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)
>>>
>>>
>>>