...
If you take a strong stand that programmers should all do something in one common way, you almost guarantee that your efforts will be subverted by people who believe that your choice is wrong. The Sandbox is not a single choice but rather a family of almost identically configured mix and match components that almost anyone can live with.
At Yale, the production environments are all "server" configurations with no user interface except the command line. While some diehards believe that the original terminal interface is the best experience, most programmers today expect a graphical desktop environment and an IDE. If you have to add Gnome or KDE, and production doesn't depend on either, then the Sandbox concept doesn't care which desktop you use.
The production systems install JBoss using RPMs that are unavailable to us and in a scattered collection of directories specifically designed for starting processes at boot time and running them continuously and non-interactively. A development environment has to debug JBoss, which means it has to be installed where the JBoss Tools in Eclipse expect it to be and to start and stop under user control. However, once you are no longer wedded to installing things in system directories, then the development environment no longer really cares if the distribution is CentOS, Fedora, or Ubuntu.
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.
Yale 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.
...
Hypervisor
Oracle Virtualbox is free, powerful, easy to use, and can be installed on all Yale computers. It is a desktop tool friendly to developers rather than a production server deployment tool like Hyper-V. Over time it gets almost all the features of VMWare Player, while VMWare itself is holding features back to justify the price tag of its Workstation product. However, the Sandbox does not depend on any features of the software that runs the VM, so if you insist on a different hypervisor that is your choice. Virtualbox is still the best utility for converting between the various proprietary Virtual Hard Disk file formats.
Desktop
Production servers run without a graphic user interface. The Sandbox development is all done in Eclipse, but it does not care about the Desktop environment that launched it. So if you want to use Gnome, KDE, Unity, or any other desktop system you are free to choose one. Any Linux OS VM we supply comes with the default of that distribution.
Virtual USB Stick
Each distribution has a place where they will normally install Java, Eclipse, and any other software they know about that can be installed with yum or apt-get or whatever. Sometimes the tool vendor supplies an RPM that puts the software in a different location than the distribution normally prefers. We use neither. All Sandbox software is installed on a virtually mountable disk (think of it as a virtual USB stick). The operating system doesn't know about any of this software. Eclipse has been configured with the location of everything else, and all you have to run is Eclipse.
You may want to move the Eclipse workspace to your real Home directory (or the /home/casdev directory since you login as user "casdev") if you are doing something experimental and don't want to mess up the original workspace in the Sandbox. If you screw up you can delete and replace it.
By implication, no matter where you think JBoss should properly be installed on a production system, the Sandbox puts it somewhere else. On the other hand, if you have already installed a Java, JBoss, Eclipse and other tools on your normal OS, the Sandbox will use its own and ignore the ones you typically use in your other work.
One from Column A
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.
Eclipse, not /etc
In the operating system servers are configured in /etc or the registry, but in the Sandbox you configure every Java Runtime, every JBoss or Tomcat server, and every Maven instance in Eclipse. In the system Java and JBoss are started at as background processes at boot time, but in the Sandbox your run Maven or start JBoss in debugging mode by clicking the task bar in Eclipse. Not only does the Sandbox not need the server installed in /etc/init.d, but if the server started up in the background there would be a conflict when you try to debug it using the same port number. So the Sandbox does not use the standard directories for Java or JBoss, and generally works better if they are not installed at all from the point of view of the OS package manager.
You can install more than one version of Java, because you can configure more than one Java Runtime to Eclipse. You can also configure more than one JBoss and also a Tomcat server. This allows you to run develop code that runs in part in two different applications. The Expired Password function has a component that runs in CAS on JBoss and a second component that runs in the Netid application under Tomcat. You can combine the two applications in a SandboxData disk, although with enough memory you can also run two Sandbox VM machines on the same host machine.
1001
There is a generic developer userid named "casdev" (because the Sandbox was first created for CAS, but it can be used for any application). This user must be configured to the OS as Linux user 1001 because that is the owner of all the directories in every SandboxData disk. The Sandbox OS is typically configured to log this userid in when you boot the VM. Typically the developer starts Eclipse and then everything is managed and started from Eclipse as part of this interactive login. So everything runs under the "casdev" user, and that user must have read and write access to the small number of OS directories that may be used during execution (specific subdirectories of /var/log and /media for example). Any directory permission problems will not show up until you run the code in DEV, but that is typically soon enough to deal with them.
R:\
The Sandbox approach can also be used with Windows, but Windows cannot share the same SandboxData directory tree. For one thing, there are executable programs in every Java Runtime and in an Eclipse directory, and these programs are system specific. Unfortunately, Eclipse also inserts a disk letter when you configured a file path in Windows but does not insert a letter when you make the same configuration in Linux. So an Eclipse workspace directory ends up being system specific even when all the files are relative and they are all moved as a directory tree from one system to the other. So there is a separate SandboxData for Windows whenever development can be done on either system.
...