...
The core of the Sandbox is a separate disk image (named "SandboxData") that contains the Java, Eclipse, JBoss, Maven, database drivers, and so on. This disk can be cloned or checkpointed so it can be shared between multiple virtual machines, even with different Linux distributions.
There will generally be a VM and a system disk that comes with a particular Sandbox instance, but it it comes with Fedora and you prefer Ubuntu, then switching the OS generally requires just a small amount of network reconfiguration.
There is a different version of SandboxData for Windows and Linux. Eclipse saves disk letters when it configures directly locations on Windows. Therefore, it is difficult to move the Eclipse workspace between Windows and Linux. It is better to keep the workspace directory for the system you are using but to import new projects into that directory if you want to change the development platform for an application from one OS to the other.
Linux doesn't have disk letters, but there are several different system mount points that have been proposed and replaced through the years for a second disk.
Fedora maintains the original view that Unix is a multi-user operating system and it regards mountable disks as owned by a user (as USB sticks tend to be). So Fedora prefers a very transient mount point and defaults to /run/media/[userid]/SandboxData.
Ubuntu, however, still uses the old model that no matter how many users share the machine, mountable disks are hardware devices like the CD. So it mounts disks as /media/SandboxData.
Of course there are other options, but the fact that two well known distributions make different choices frees us from expecting that there is one right answer to this question. Therefore, the system will put the disk where it wants to, and any further conventions we create will be symlinks to that system mount point.
However, the rule that the Sandbox is absolutely separate from the RPM or apt-get installed versions of the same program would prohibit configuring symlinks so /opt/eclipse points to /media/SandboxData/opt/eclipse. That could collide with the real OS install of Eclipse. So the Sandbox on linux needs a path that works on all systems, and /media/SandboxData seems to be a middle of the road choice. It implies a degree of impermanance (so you can eject one disk and mount a different one if you want to work on a different project) but also a degree of durability (so you can make symlinks to a specific path).
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 matterthe VM manager (VirtualBox) can create a fixed base disk shared by multiple machines with separate difference files that hold the changes each VM makes.
The last programmer to work on an application will leave a VM with a particular version of a particular OS that was last used in development. Try to live with it. If you can't, then you can switch to another OS Sandbox disk, but then you will have to connect it back to the SandboxData disk that contains the development files.
This is a three step process in Linux:
- You have to configure the VM (the *.vbox XML file) using the GUI configuration tool to have two SATA disks, one for the OS and one for the Sandbox.
- You then have to configure the OS to mount the second disk to a well known mount point. This uses the "disks" GNOME utility which is an easy to use way of changing the /etc/fstab file.
- Because the "well known mount point" may change from OS to OS, it is safest to create a symlink to the SandboxData from some directory that will never change to the well known mount point on that system. Then if Eclipse and all other tools are configured to use the symlink path, that configuration is guaranteed to work all the time.
In Windows you just make the SandboxData look like it is the R: disk.
Linux and Windows are both multiuser operating systems that are mostly used by a single user at a time. In both systems, there are ways for an administrator to mount a disk that everyone shares, but there are also ways that a single user can access a disk over the network that is only visible to him. Inserting a USB flash drive in a port or a DVD in the optical drive may be more personal, while opening the covers and mounting a new SATA hard drive in the machine seems to be more permanent and system wide. In reality, this is all a matter of configuration.
Fedora defaults to mounting new disks in a personal transient way. It would create a mount point named /run/media/casdev/SandboxData (for user "casdev"). The /run directory holds things that changed since the system booted up, so this path implies something quite temporary.
However, Linux used to mount a CD in /media/cdrom, and Ubuntu maintains that convention by defaulting the new disk to be /media/SandboxData.
Of course, you can use the "disks" graphic configuration tool to create an /etc/fstab file (the text file that really controls things) to mount the disk in either location, or anywhere else.
Generally, we expect that the SandboxData disk will appear to be at /media/SandboxData, and if you don't directly mount it there with fstab then create a symlink there to the real mount point.
There is another technical problem. When a disk is first formatted it is assigned a unique identifier (a uuid) in the disk label. This allows external disks to be uniquely identified, and it also helps the computer to sort things out when you have to do some work inside the machine and the SATA cables become disconnected and are then plugged into the mainboard in a different order. To us, this means that although the SandboxData name is the same for each application work disk, internally each verison of SandoxData has a different uuid and the configuration in /etc/fstab is driven by the uuid on the disk. So if you disconnect one SandboxData from a Linux OS and then connect a different SandboxData, you will have to rerun the "disks" Gnome utility to edit /etc/fstab with a new entry for the new uuid.
Fortunately, if you always mount disks as "/media/SandboxData" then any symlinks to a subdirectory of that mount point will work and they do not depend on uuid.
The choice of symlink is arbitrary, but the one convention we must adopt is to not use any location for the link that could conflict with the real version of the standard application when it is installed with a package manager. Therefore, the symlinks should not go in /opt or /usr.
Installation
Conceptually the Sandbox can run on VMWare Player or Hyper-V, but the disk format has to be converted and if you intend to use the supplied OS disks, then their drivers should be updated. Generally speaking, VirtualBox turns out to be the tool everyone points to when they want to convert a virtual hard disk file from one vendor format to another. So you may need to install VirtualBox as a tool even if you want to try to use a different VM host software.
...