RT Repo Structure, and tests repo

[Daniel Zwolenski]

If it's not too hard a change, I'd vote for 'core' being called 'util' (or 'common', 'general', 'ancillary', 'support', etc). Its just as generic a catch-all but 'core' to me implies the foundation on which things are built (for me the core of a ui kit would be the window/rendering stuff), whereas this one is more like the ancillary utilities that are common to the rest of the framework. JavaScript for example is used in a couple of places but I personally wouldn't call it a 'core' component. 

This would likely help the problem of people wrongly raising bugs against 'core'. I definitely got that wrong on a number of occasions (sorry Michael).

You have charts listed twice. Is the control one correct or a typo?

Otherwise it reads nicely from my side of the fence. Good balance between modularisation and practicality. 

On 22/12/2011, at 4:53 AM, steve.x.northover at oracle.com wrote:

> 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