...
So if you have a particular distribution you prefer, or you like to be leading edge, or you prefer a specific desktop (Gnome, KDE, ...), then the Sandbox can be configured the way you like it.
Thanks to Java, you can develop CAS on Windows, then run it on Linux without a problem. Therefore the choice of the OS is only an issue if the application requires a particular library or interface that isn't available on specific systems. GSSAPI, for example, behaves differently on Windows and Linux even though it is a standard Java API. If you are testing things that depend on the system like clustering and failover, then using Linux for that testing is the best policy.
A separate copy of the Sandbox may have been archived by the last person who worked with a particular application. If you pick it up and use it as is, then you can get right into development. If you only have a few changes to make, you can be done before you would have had a chance to make any system configurations.
However, if you feel strongly about KDE or Gnome or the version of Eclipse that was released last week, then an alternative is to keep your own personal optimized system disk. Then you only swap the SandboxData disk that contains the application, workspace, and JBoss. Because every SandboxData disk contains the same directories in the same places, the OS disk can have symlinks to the various components that remain valid even when you change disks. It is conventions like this that make the Sandbox a concept and strategy rather than a single imageYale tends to use the Oracle Virtualbox software to create desktop VMs. This software is easy to install, perfectly adequate for the purpose, and is relatively friendly and easy to use. However, a virtual machine image should not be strongly dependent on the hypervisor, and any use we make of Virtualbox specific features is only to achieve extra convenience and not to perform any tasks essential to the Sandbox. So if you have a Windows machine with Hyper-V installed and used for other projects, then you can certainly adapt the Sandbox VM to run under that host environment.
Generally speaking the Sandbox VM environment involves choosing two separate components.
- You need an OS VM. Typically it will run CentOS, Fedora, or Unbuntu. You can just pick up the OS configuration last used for the software you are planning to develop, or you can choose one specific OS VM to use for all your development and customize it to your preferences.
- You need the SandboxData disk/directory-tree for the particular software package you are planning to work on . By separating out the CAS project files on one virtual disk, and the Netid project files on another virtual disk, you can keep the same OS VM with your customizations and switch from one software development project to another by switching mounted disks.
Different Linux distributions put the same component in different directory locations. There is no single correct place to install a program, and if you decide to use your own customized environment to perform the Sandbox development function you may have already installed some of the same programs in the location you prefer. The only safe thing is for the Sandbox to provide all its own copies of every program on which it depends and to put all this stuff in a separate location that cannot possibly conflict with any default "system" version of the same code. So the Sandbox is packaged as a separate small self contained virtual disk drive that you mount as an additional disk on a base operating system.
...