RT Repo Structure, and tests repo

[Daniel Zwolenski]

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.


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

In general looks good though.

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

Tools would be good.


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