RT Repo Structure, and tests repo

[Richard Bair]

>> Good question. The way Jemmy works, is that it has some fluent interface for testing the UI Controls. So whenever we add a control or add some new method to a Node or whatnot, JemmyFX needs to be updated. So if it is an external project, then it will need to be rev'd pretty regularly and everybody will need to download the latest version fairly regularly (as in, more often than not). So the idea was to cut that short by just including the testing framework in a test repo in the forest, so we can just update it as we go.
> 
> What you need here is a little tool called maven :)
> 
> End of the day it won't matter too much where it lives in open source land. It's just a bit odd if it's 'official'. jfx is maintaining integration with jemmy, why not other testing kits, etc?

True that.

>>> 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
>>> 
>>> Can we get a one liner on what each of these modules are for? I'm curious what concurrent is and what's in core vs graphics, etc? 
>> 
>> charts is, well, charts :-)
>> concurrent: the javafx.concurrent package (Worker, Task, etc)
>> controls: controls
>> core: javafx.util, javafx.beans, javafx.collections, etc
> 
> We definitely want these all as one? I always get a little suspicious when something is called 'core' or the like. It's a bit of a catch all. 

They will be broken down into sub modules, so core would have javafx-beans, javafx-common, etc as sub modules. I guess by this logic concurrent could be a sub module of core as well... I'm happy to hear other proposals on how to break it up.

>> fxml: fxml
>> graphics: CSS, scene graph, prism. Maybe glass should actually be a different top level module and not a sub-module of graphics
>> layout: javafx.scene.layout
>> media: javafx.scene.media
>> swing: javafx.ext.swing
>> swt: javafx.ext.swt
>> web: web view
> 
> Where do animations live?

Graphics, I think.

Richard