RT Repo Structure, and tests repo

[Daniel Zwolenski]

On 21/12/2011, at 4:45 PM, Richard Bair <richard.bair at oracle.com> wrote:

>> In general better modularisation sounds good. Comments inline. 
>> 
>> On Wed, Dec 21, 2011 at 1:33 PM, Richard Bair <richard.bair at oracle.com> wrote:
>> 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.
>> 
>> Should JemmyFX not maybe a separate .net project that the unit test part of JFX uses. i.e. much the same as Jemmy is. You may have trouble with this because as Oracle you have produced the code and getting things open source is not that easy for you guys. But if you weren't Oracle, and were just developers like us, then that's what you would do. 
> 
> 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?

> 
>>  
>> 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. 

> 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?

> 
> Although some of these modules are very small, they are separable, so it makes sense to break them out even if they are small (since we combine things together into jfxrt.jar in the end anyway, having a lot of modules doesn't hurt the final configuration any).

Sounds good. Just so you know this is how maven likes it. It should make this easy to create pom's for and deploy to repos once it is all open with friendly licences. Bonus. 

> 
> Thanks!
> Richard