RT Repo Structure, and tests repo

[Richard Bair]

A little while ago I gave an overview or description of the current build system [1]. In this message I covered two ideas that I want to revisit now. The first was that we want to cut down the number of repos into our forest into basically this set:

	jfx/		- This is the root forest
	jfx/apps	- As presently constituted
	jfx/webkit	- WebKit, plus our patches to webkit (but no Java code)
	jfx/gstreamer	- GStreamer, plus our patches (but no Java code)
	jfx/rt		- The bulk of the platform
	jfx/tests	- The functional or SQE related tests (all tests not JUnit tests)

This item in bold, jfx/tests, is a new proposed repo in our forest (actually, it already exists but now we want it to also exist in the open source). The idea here is that JemmyFX (the JavaFX extensions of Jemmy) and the bulk of the functional tests that have been written by SQE using JemmyFX would both go into jfx/tests repo. This would do a couple things. First, if anybody else wants to write JemmyFX-based tests for their own applications, the code would be available for them to do so. Second, for anybody wanting to help write tests for the platform to improve our code coverage and stabilty, the tools would now be available to do so. Third, if you are fixing any bugs in the core platform, you will have the tests available to make sure your fix doesn't introduce a regression. And fourth, if you want to submit a new API (such as a new control or just a new feature on some existing class) then you will have the tools available to also write a pile of functional tests.

If there are no objections, then I'll ask Mark to create us a new jfx/tests repo. Due to the pending holidays, this will likely be something we'll see achieved early / mid January (created + populated).

The second issue I brought up in that former email was the issue of organization for projects within rt. In the old closed runtime, we have a whole bunch of projects in a flag hierarchy, but in openjfx we want to organize things a little better around modules. Although the existing code has always been modular, it isn't clear from the directory layout what is part of what module, or what modules are public, or which modules are optional, etc.

Steve Northover took a first pass and came up with these top-level modules:

charts
concurrent
controls
core
fxml
graphics
layout
media
swing
swt
web

There are also a few projects (well, one anyway) which is unit test infrastructure related, and two projects which are design-time related. We should probably also then add another module called "tools". Each of these modules would get a top-level directory in rt, and the corresponding projects which represent the implementation of the module or submodules or optional modules would then be projects within these directories.

Within the "graphics" module would be scenegraph, prism, decora, and glass. Within these directories would be the projects related to each of these. Now, since the rest of the platform hasn't made it into openjfx yet, we can still make some adjustments to this as we go. However what I would recommend is that we reorganize so that of the 6 projects either currently open source or about to be, we organize them such that:

rt/
	concurrent/
		javafx-concurrent
	controls/
		javafx-ui-controls
	core/
		javafx-util-converter
	tools/
		javafx-beans-dt
		javafx-designtime
		test-stub-toolkit

We can then continue building on this in the future. What do you think? If y'all are good with this, I'm happy to move on it and have it straightened out before the break, so we can start clean in the new year :-).

Thanks
Richard