This doesn't answer your actual question, but may be of help.
Consider cross platform tools
There are layers such as PhoneGap, that would allow you develop apps accross multiple platforms in one language.
Also, a cross platform language, such as haXe might be of interest (you can use the C++ backend for native apps, and the JS backend for web and mobile apps (through the aforementioned PhoneGap)).
You can drastically reduce the amount of code you need to write, if you can reuse it on multiple platforms. Having less code in the first place, solves many problems before they even occur.
Focus on a single platform to start with
If you try to write the app for many different platforms at once, the results may become mediocre. Instead, you should rather try to pick a single platform, to focus on. Test the concepts of your app on that platform and then port it to other platforms and adapt it accordingly.
For example, you may realize, that you don't actually want the different ports to share graphics, to better fit with the graphical needs. For example on the iPhone 4, you have a very high resolution, so you might need extra icons for that. Also, the users may have different expectancies.
Porting a working concept to a new platform is relatively straight forward (although sometimes work-intense), in comparison to really developing it in the first place. If you try to do that on multiple platforms at they same time, you may overburden yourself.
So pick a platform, that is sufficiently widely spread and that you feel comfortable with, to get up and running quickly. A user base is a valuable source of feedback, that you'll hardly get anywhere else.
Do not think too big. Start small and grow.
This applies not only to your initial choice of platforms, but also to your projects setup. Adapt your toolchain according to your needs instead of investing time on building up a giant all-purpose environment, that is actually putting a lot of overhead on your development process.
You want to tackle a non-monolithic problem. As a consequence, I think a behemothish, monolithic workflow is maybe not the best thing to do.
You have to use stage
given to start
method as your main Stage because it's created for you by JavaFX startup logic (and it can be desktop stage, jnlp one, or a plugin in the browser so you better not create it yourself).
If you need another windows in your application (dialogs, warning, popup windows, etc) you can create new Stages. You can use them as new Stage()
objects or subclass, at doesn't really matter or affect performance (IMHO).
Best Answer
The source tree layout should reflect the architecture; as a corollary, a well-structured architecture can lead to a well-structured source tree layout. I suggest reading up on the POSA1 Layers pattern, attempting to fit your architecture into a layered structure, then naming each of the resulting layers, and using that as a basis for your source hierarchy. Taking a common three-tier architecture as a baseline:
Note that the layers do not contain code directly, but rather are strictly used to organize modules.
Within a module, I use the following sort of layout:
<module>
(path to module directly; defines modular interface)<module>/impl/<implName>
(a specific implementation of the modular interface)<module>/doc
(Documentation for using the module)<module>/tb
(unit-test code for the module)where the
<module>
is located in the repository according to the layer to which it belongs.