RT Repo Structure, and tests repo

[Michael Heinrichs]

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