Attempting to Build [ was Source code for JavaFX UI controls now available on openjfx]

Kevin Rushforth kevin.rushforth at
Wed Dec 7 02:13:44 PST 2011

Btw, I know what the cause of is (I updated the bug 
report). We rely on ant-contrib for a few tasks and propertycopy is one 
of them. Until we get the top-level build wired up, the solution is for 
developers to do the following manually:

mkdir import
cd import

and unzip it into the import/ directory such that it ends up in 

Then you can build from JFXROOT/rt/javafx-ui-controls without commenting 
out the propertycopy class.

As Jonathan indicated, the idea is to gradually improve the ability to 
build from just the open sources, but for now this is a solution that 
developers can use.

-- Kevin

Jonathan Giles wrote:
> I don't believe this variable is fully implemented. I actually define 
> the same property up in the rt/build-defs.xml file, but there needs to 
> be some more work in the javafx-ui-controls folder to only use this 
> reference. I've made some half-attempts at getting this all hooked up 
> in the past, but haven't yet completed it. There are a number of paths 
> that need testing:
>     * compile from rt-closed,
>     * compile from 'jfx'/root directory with 'ant clean dev-build',
>     * compile from within javafx-ui-controls folder,
>     * compilation from within NetBeans.
> Also, it's worth noting that in the same part of build-defs.xml I pull 
> in all environment variables, so if the developer simply sets 
> JFXRT_HOME to a path on their file system in the environment settings, 
> this should be picked up (although with the caveat that ant doesn't 
> apparently support environment variables in all operating systems).
> Once I'm back from vacation, if nobody else has taken a look at 
> JFXRT_HOME improvements (and indeed whether we should be pointing at 
> JFXRT_HOME, or more simply JFX_HOME (which may be a directory or two 
> higher up the path)), I'll take another stab at it.
> -- Jonathan
> On Wednesday, 7 December 2011 10:20:28 a.m., Richard Bair wrote:
>> Ya the property is in javafx-ui-common/ called 
>> JFXRT_HOME. If you just set this property then you don't have to 
>> manually move the jfxrt.jar into artifacts/sdk/rt/lib.
>> Thanks for filing the issue!
>> Richard
>> On Dec 6, 2011, at 4:16 PM, Kevin Rushforth wrote:
>>> Regarding #4 I think Jonathan added a property (or was going to add 
>>> one) so you don't have to copy it in, although copying it may be the 
>>> easiest way to do it anyway.
>>> Regarding having to comment out the propertycopy ant task, I filed 
>>> to track this.
>>> -- Kevin
>>> Richard Bair wrote:
>>>> The missing scripts have been pushed, so I think I can now give 
>>>> reproducible instructions for building and testing. Download the 
>>>> 2.1 binary for Mac from 
>>>> 1) hg clone
>>>> 2) cd master
>>>> 3) mkdir -p artifacts/sdk/rt/lib
>>>> 4) cp ~/Downloads/javafx-sdk2.1.0-beta/rt/lib/jfxrt.jar 
>>>> artifacts/sdk/rt/lib
>>>> - Or from wherever you have downloaded this file
>>>> 5) hg clone
>>>> 6) vi build-defs.xml
>>>> - There is some library being used but not registered properly, 
>>>> there is probably another way to do this.
>>>> Anyway, just edit the master/rt/build-defs.xml and comment out the 
>>>> line:
>>>> <propertycopy name="javac.debuglevel" 
>>>> from="${}.javac.debuglevel" silent="true" 
>>>> override="true"/>
>>>> 7) cd javafx-ui-controls
>>>> 8) ant
>>>> That should be enough to actually have built the project. The built 
>>>> class files should be sitting in 
>>>> master/rt/javafx-ui-common/dist/javafx-ui-controls.jar. You can 
>>>> then run by placing the newly created javafx-ui-controls.jar before 
>>>> jfxrt.jar on your classpath.
>>>> Let me know if you have any success!
>>>> Thanks
>>>> Richard
>>>> On Dec 6, 2011, at 9:46 AM, Richard Bair wrote:
>>>>> If you got to and download JavaFX and find the tiny 
>>>>> link that switches to the Mac Developer Preview download and grab 
>>>>> it, you will get a very recent 2.1 build. This can be used as the 
>>>>> binary plug for building. Unfortunately, some build files are 
>>>>> missing in the master/ repo. I tried to push these files in, but 
>>>>> the server is not happy with my ssl configuration. I'm trying to 
>>>>> track that down. With those build files put in, there is one other 
>>>>> slight modification to master/rt/build-defs.xml, but this will 
>>>>> then allow you to actually build the controls repo and, if you are 
>>>>> on Mac, run it.
>>>>> I'll keep you all abreast of the work, hopefully we'll have 
>>>>> something fully buildable a little later today.
>>>>> Richard
>>>>> On Dec 2, 2011, at 5:43 PM, Richard Bair wrote:
>>>>>>> Sorry I misunderstood, I was expecting something similar to the 
>>>>>>> binary plugs we had in OpenJDK, not a full version of the 
>>>>>>> current release, hence the question.
>>>>>>> I was able to import the project successfully into eclipse (and 
>>>>>>> netbeans) with the FX runtime and it seems to compile fine.
>>>>>> Oh, that's interesting. I grabbed the latest 2.0.2 code for Mac 
>>>>>> that I had available but it was failing on:
>>>>>> [javac] 
>>>>>> /Developer/Projects/openjfx/workspace-2.1/master/rt/javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/ 
>>>>>> cannot find symbol
>>>>>> [javac] symbol : class PlatformUtil
>>>>>> [javac] location: package com.sun.javafx
>>>>>> [javac] import com.sun.javafx.PlatformUtil;
>>>>>> [javac] ^
>>>>>> And a bunch of other such failures. So I thought PlatformUtil had 
>>>>>> been removed between the 2.0.2 code I had (from early November) 
>>>>>> and the newer code in the 2.1 tree. If you got it to build in 
>>>>>> Eclipse on an older release -- well that is interesting! What 
>>>>>> version of JavaFX are you using for the binary plug?
>>>>>> Do you want to post some basic instructions so other folks can do 
>>>>>> likewise?
>>>>>>> I'll play with this code a bit and see how we can help out until 
>>>>>>> everything else is sorted out.
>>>>>>> I think that while this is a suboptimal situation (but hey, we 
>>>>>>> Free Software freaks are never happy, right? :) is still a great 
>>>>>>> step forward, and we have a chance to study the code and the 
>>>>>>> internals before everything gets released.
>>>>>>> Speaking about this, do you think we can have some "specs" about 
>>>>>>> the internal interfaces?
>>>>>> Probably in the short term asking me questions is the fastest way 
>>>>>> to get answers, unfortunately. I do need to be badgered to write 
>>>>>> up some documents though and put them up on our pages. Please do 
>>>>>> feel free to badger me: squeaky wheel and all that :-)
>>>>>>> I know from JavaOne that the internal code is pretty abstracted 
>>>>>>> and modular, and can actually be "easily" replaced (not sure the 
>>>>>>> exact definition of easily though, but what you have shown at J1 
>>>>>>> was very impressive).
>>>>>>> We can probably help speeding up things if we know what things 
>>>>>>> should be replaced and implement some clear room version of what 
>>>>>>> will come later in the game, in a similar way we did with the 
>>>>>>> Pisces renderer in Java2D, what do you think?
>>>>>>> I'm specifically thinking about the Linux port here, since to be 
>>>>>>> honest "late 2012" is eons away.
>>>>>> What we have released so far is the controls portion, which all 
>>>>>> sits above the "toolkit implementation" line. Basically on the 
>>>>>> "top" we've got controls, scene graph, css, properties, binding, 
>>>>>> collections, services, and that sort of thing. There is a Toolkit 
>>>>>> interface ( which defines the 
>>>>>> abstraction between the public API portions of the platform and 
>>>>>> the underlying toolkit implementation (threading, windowing, 
>>>>>> opengl, d3d, fonts, etc).
>>>>>> Likely it will be a couple months before we start putting out the 
>>>>>> lower-level bits en masse, due to having to be careful there over 
>>>>>> 3rd party code etc (there isn't much, mostly fonts and some SVG, 
>>>>>> but we have to do all the due diligence). The other problem is 
>>>>>> the same guys who have to do that, have to get the Mac port 
>>>>>> finished (both for Java 7 and for Java FX). However I will follow 
>>>>>> up with the guys doing linux and see if we can get that out 
>>>>>> sooner (they're busy working away on it and it would be cool to 
>>>>>> get it open faster, but at the very least get it included in the 
>>>>>> bits so you can run on linux).
>>>>>> Cheers
>>>>>> Richard

More information about the openjfx-dev mailing list