...
The solution was to create two separate virtual hard disks. One disk holds the system you have chosen to use (which mostly doesn't matter). The other holds some Java runtimes, Eclipses, some Mavens, some JDBC drivers, some JBoss or Tomcat instances, and some starter Eclipse workspaces.
Ideally the two would be independent. However, there are a few executables that are different in Windows and Linux, so the Java Runtime, Eclipse, and JBoss are either Linux or Windows and there have to be separate versions of the development disk for the two platformsthere second disk could be shared by everyone, but the java, javac, eclipse, and other executable programs are system dependent and even the Eclipse workspace ends up remembering system dependent path information. So there are two versions of the second disk, one for Linux and one for Windows. The format of these two disks is identical (same directories, same contents, just different executables).
In Windows the second disk is mounted as the R: disk. In Linux it is mounted in the same way that Linux likes to mount portable disks or thumb drives (as /media/SandboxData).
There is almost no specialized configuration on any operating system. This paper will provide suggestions for configuring the virtual network that are useful guidelines for development, simple debugging, and complex debugging. However, you can use almost any version of any operating system as long as machines that run the IDE (Eclipse) have a GUI and desktop.
This also means that you can customize your OS to be exactly what you want, then use it with different SandboxData disks to do development on different applications (or you can put all the applications on the same SandboxData disk and run them all together).
Sandbox systems tend to be kept more up to date than production systems. If you really want to try something new out while working, it is not unreasonable to work with a stable Beta of the next release of the OS. Having the latest features at hand can be useful.
The SandboxData disks, however, tend to lag behind because they have to match an environment that is already in production. So you will find Java 7 instead of 8, or JBoss EAP 6.2 instead of Wildfly 9.
The Sandbox allows you to edit and debug source. You can change existing files and create new files. You can work with Java source or configuration files. After you are done with basic testing, the changes you make are committed back to the Yale Subversion server. Then they are then used by the Jenkins jobs to build the DEV, TEST, or PROD environment.
So the result of Sandbox development is reflected in changes to SVN. After code goes into production, you can keep your copy of the Sandbox around for further development, or you can discard it and start over again with a fresh new Sandbox in any future project. If you have strong feelings about Linux or Eclipse, you may choose to customize your Sandbox VM to your preferences, and then it makes sense to save it and use it for other development, even for other software projects.
Installation
You need a current version of VirtualBox which you can get from Oracle (virtualbox.org). You can install it on a Windows or Mac desktop or laptop computer which becomes the "host". If you are already using the R: disk letter for something else, it will be vastly easier to move the old data and free up the letter than to try and find and reconfigure all references to R: that Eclipse has stored away.
In Linux there were many possible places to mount the second disk. Most Linux directories are for permanent files. There can be more that one Sandbox, and you may switch from one to the other when you change the project on which you are working. On the other hand, the Sandbox probably should not look as transient as a thumb drive you plug in temporarily, which in Red Hat systems is in "/run/media/[userid]". The generally accepted place for files of medium persistence seems to be in /media, specifically /media/SandboxData.
The Sandbox OS may be more current than the production system. Java applications don't care if they run on Windows or Linux, so they clearly don't care about the difference between Centos 7 and Fedora 22. You may find the lastest system features more convenient, or you may prefer the old version of the desktop and hate the changes in the latest version of Gnome.
The SandboxData disk, however, has to make old versions of Java and JBoss available because the applications really do care about those options. If you work on one application at a time, then you may have a SandboxData optimized for just that one application. However, development on CAS sometimes requires changes to Shibboleth and to Netid, and those three applications run on different versions of Java, and while CAS runs on JBoss 6, Shibboleth runs in production on JBoss 5 (although it can run on 6), and Netid requires Tomcat. So you may use a SandboxData disk with all of the versions needed by all of the systems.
The Sandbox system allows to to edit, compile, and debug the program. After debugging, the Sandbox commits source changes back to Subversion. To move those changes even into DEV requires a Jenkins Build job that checks the source out of Subversion, reruns the compile, and stores the JAR or WAR on the Artifactory server. So the only external consequences of the Sandbox development are the source changes in Subversion. Except for that, everything that happens in the Sandbox is private and doesn't matter.
Normal Installation
Development doesn't care about which virtual machine host you use, but we have to choose something. VirtualBox is free, open source, quite easy to use, and available for all the host operating systems we use. Normally you install the current version of VirtualBox. Normally you use the lastest version available from virtualbox.org.
You can decide to use your native desktop or laptop operating system and bypass the VM entirely. This should not be your initial choice. It is better to start with VirtualBox and the VMs, get used to the Sandbox development, and then later on if you do a lot of work with IIQ or CAS, you can promote that development to your native host OS.
You will need admin privileges on your machine to get the mount points, symlinks, and the network configuration just right. Using VMs provides a layer of security because the VMs and their virtual network can be hidden inside your machine entirely separate from the real network that you share with others.
VirtualBox is an open source project, but Oracle also creates provides some proprietary extensions that you are prompted to install immediately after you install the base software.
If you launch the VirtualBox application you will see a management console. It displays the Virtual Machines (VMs) that you already have and provides a Wizard for creating new VMs, typically by running the OS installer CD image for Windows or a Linux distribution. If you ask it to start an existing VM, VirtualBox creates a simulation of a full personal computer and even runs a power up BIOS. It then boots from the virtual hard disk image or from the virtual CD image.
The VM displays on the host computer screen as an application window. However, this "application" thinks that it is an OS on a real computer. To make it behave seamlessly on the host monitor, VirtualBox provides some device drivers that you can install on Windows (or build and install on Linux). With the drivers the mouse can move smoothly into and out of the VM window, and cut and paste of text operates between VM applications and host applications.
Once installed, the VM will be a directory of files in the location VirtualBox is configured to store its VMs. This VM is configured by the installation process with specific locations on the host disk and the names of specific configuration features from that specific host. So you to install the VM on another computer, you have to "Export" it to a type of file that is not bound to one specific .
After installing a new OS, you can mount a virtual CD on the virtual machine and install Linux or Windows Guest VM device drivers. These drivers know about the VM environment, they provide more flexible screen management, and the ability to cut text in the host operating system and then paste it into an application running on the VM (or the reverse). VirtualBox is slowly working on the ability to drag and drop files between the host and the VMs.
A specific restriction on VirtualBox is that the files that it creates to represent the VM and its hard disk are configured with fully qualified path locations, and they contain references to LAN adapters and audio cards on the host machine. They cannot simply be copied from one place to another without fixing this configuration. You can edit the XML in the *.vbox XML file, or you can use the VM clone function to get VirtualBox to make a copy of the file in a new location, or you can Export and then Import the VM on another system.
The Sandbox is distributed as a Exported *.ova file. This is an open standard form of zip file that contains both the machine configuration and the disk image. It can be loaded into VirtualBox (or VMWare for that matter) to create the virtual machine. During installation, or any time before you start the VM, you may need to configure features that are potentially dependent on your local machine configuration. VirtualBox has a feature called "Shared Directory" that allows the host operating system to share one of its directories with the VM (like a network share, but implemented without the network). When the distribution was built, the shared directory was "D:\sandbox", but you may want to turn this off (it is a convenience) or change the host directory path, especially if you do not have a D: drive or are not running Windows on your host computer.
...