RT Repo Structure, and tests repo

[steve.x.northover at oracle.com]

Hi folks,

I realize that "core" is a pretty meaningless name but it is in common 
use inside and outside of FX.

It's quite true that we could break FX into many more smaller modules or 
larger ones (we are using the term "modules" here, but what we are 
talking about is a hierarchical structure of functional units, each 
building on the other).  Like Richard said, FX is quite modular but this 
is not captured anywhere (yet).  Having FX organized this way sooner 
rather than later makes sense.  The hierarchy means that at some point 
in the future, it might be possible to run with a subset, for example a 
headless mode.

This breakdown seemed reasonable to me (ignore the javafx- prefix):

javafx-charts
     javafx.scene.chart

javafx-concurrent
     javafx.concurrent

javafx-core
     javafx.beans
     javafx.beans.binding
     javafx.beans.property
     javafx.beans.value
     javafx.collections
     javafx.event
     javafx.util
     netscape.javascript

javafx-fxml
     javafx.fxml

javafx-graphics
     javafx.animation
     javafx.application
     javafx.builder.processor
     javafx.event
     javafx.geometry
     javafx.scene
     javafx.scene.effect
     javafx.scene.image
     javafx.scene.input
     javafx.scene.paint
     javafx.scene.shape
     javafx.scene.text
     javafx.scene.transform
     javafx.stage

javafx-layout
     javafx.scene.layout

javafx-media
     javafx.scene.media

javafx-swing
     javafx.embed.swing

javafx-swt
     javafx.embed.swt

javafx-web
     javafx.scene.web

javafx-controls
     com.javafx.preview.control
     javafx.scene.chart
     javafx.scene.control
     javafx.scene.control.cell

Although graphics could be broken down further and things like animation 
separated out, I considered that this would make too many modules.

Steve

On 21/12/2011 4:23 AM, Michael Heinrichs wrote:
> Hi,
>
> On 21.12.2011, at 07:53, Richard Bair wrote:
>
>>>> 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.
>>
> I think, it is ok to have javafx.beans (which could be split in two sub-modules properties and bindings btw.) and javafx-collections close together. Often major design choices in one area affected the other. But the name is really bad. "Core" does not mean anything to people unfamiliar with JavaFX. I can see that in JIRA, where I get all kinds of bugs and feature requests linked to the "Core Libraries", which in fact are just properties, bindings, and collections.
>
>
>>>> 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.
>>
> Mmmh, the animation API is completely independent from the rest in Graphics. You can easily use it in a program that does not use the SceneGraph at all. I think it should remain separated. Only the graphic-specific transitions (FadeTransition etc.) should remain in the graphics repo.
>
> - Michael
>
>> Richard