Open Sourcing Status Report

[John Smith]

Thanks for the hard work on open sourcing JavaFX.
I noticed some of the fxml work was open sourced recently, so that's progress.

Looking at the repository, this is a list of modules currently open sourced:
  javafx-beans-dt
  javafx-concurrent	
  javafx-designtime	
  javafx-fxml	
  javafx-ueber-jar	
  javafx-ui-charts	
  javafx-ui-common	
  javafx-ui-controls	
  javafx-util-converter	
  test-stub-toolkit
I also think WebKit source modifications are open source somewhere.

It would be nice to have an equivalent list of modules which will be open sourced.

For example, it is unclear to me whether or not things like the browser plugin, the packaging infrastructure (javafx ant tasks and javafxpackager source) and the packager embedded launcher and fallback code will be open source.  Also, will all of the code for the native libraries supporting prism, glass, media, opengl and direct3d bindings be open source by February?

In terms of project infrastructure, any chance that github could be used as the primary infrastructure or as a mirror of the existing infrastructure (similar to how redhat manage Ceylon https://github.com/ceylon/)?  Access via github might help the project feel a little more accessible and a bit more like a community project than an Oracle project.   Just asking, I understand if the answer to that question is no.

- John

-----Original Message-----
From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Richard Bair
Sent: Thursday, October 18, 2012 11:42 AM
To: openjfx-dev at openjdk.java.net Mailing
Subject: Open Sourcing Status Report

I wanted to give a status report on where we're at in the process of open sourcing JavaFX. Obviously we started this process earlier this year or late last year (UI Controls went out either last December or this January, I don't remember exactly), but it stalled awaiting internal approvals, but now that those have been cleared, we're moving forward as quickly as we can.

For each chunk of code that we open source, we need to perform the following work:
	- Update the build system to build the open source bits
	- Review for Security
	- Sanity check headers
	- Review rights (some parts like T2K are licensed and cannot be open sourced)

The long pole in this process is the "review for security". In some parts of the code, as we audit we may find a potential security hole. Much of the code we will be able to simply fix and then release (or may have no issues anyway in which case it can just be released after audit), but there will likely be some parts that need to wait until the next security release in February 2013 before we can even apply the patches to the workspace, let alone open source the code. I'm hoping this latter category will be small and that most if not all of our code will be clean and we can push before next February. But just a heads-up that it may take until February for the process to complete.

In addition, I'm engaged in a proposal for revamping the project structure and build infrastructure. My main goals are:
	1) Make it trivial to develop JavaFX using an IDE
	2) Allow for partial builds, cross builds (especially speaking of native compilation. Compiling WebKit can take an hour on my system)
	3) Download dependencies dynamically
	4) Reduce the number of lines in our build script(s)
	5) Simplify the project structure

Over the last 4 years things have grown to be quite difficult and cumbersome, and on embedded David Hill said he is spending upwards of 40% of his time wrestling with the build system. Further, only a few of us use IDE's to their maximum potential, and only after wrestling quite hard with the system and coming up with our own "magic sauce" for how to build JavaFX. Clearly this isn't scalable or desirable.

To declare success, the process needs to be as simple as:

	1) Download the Sources
	2) Use your favorite IDE to open the project
	3) Hit run

If I have to concede defeat, then there might be a 2b)
	2b) execute a build step to download dependencies

I'll send a separate email in a moment discussing what I want to do around project structure (ie: source file layout etc) and the build. Most of our time at present is spent on Security audits, and as soon as we get those done for some chunk of code, we'll move it into the open.

Richard