...
Oracle Virtualbox is free, powerful, easy to use, and can be installed on all Yale computers. Windows, Mac, and Linux computers. Other options (Hyper-V, Xen, VMWare Player) run on single operating systems so you have to convert VMs from one to the other (and it turns out that Virtualbox is the recommended utility for a lot of the conversions). 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 EclipseVMWare has been around longer and goes through more extensive testing before much more infrequent releases, but if a feature breaks when there is a new release of Windows or Ubuntu, then you have to wait a long time for the next release to fix it. Virtualbox has frequent releases as an open source project and adapts more quickly.
Although Virtualbox aspires to be something you could use for production servers in a machine room, it is not yet something one would recommend over an alternative like Hyper-V. However, for simple desktop edit, compile, and debug it is simple, reliable, and convenient. It may be that the drivers for the emulated video card don't support modern features, and that the passthrough of USB 3 hardware devices to the VM has problems. You don't need that stuff to run Eclipse.
Desktop
Originally the Production Services group at Yale tried to convince use to use the same VM in development that they use in production. However, that VM only has the character terminal user interface, and most people these days do not want to write code using only the vi editor. So to use that machine you would have to use Eclipse on another computer, then install onto the VM and remotely debug. It is a possible model, but it turns out that Production Service never provided the tools needed to actually create and maintain accurate versions of their VMs.
It is much simpler to upgrade the VM to include a real desktop and run Eclipse on the VM itself instead of on a separate machine. Given that any user interface is an addition, there was no particular reason to prefer Gnome to KDE to Unity or any of the other choices you make from one Linux distribution to another. Eclipse will work under any Linux "desktop" system. If you feel strongly about it, switch to whichever one you want.
Cutting and pasting text with the "clipboard" function and dragging and dropping files are functions actually performed with the user interface and not the Linux OS. Virtualbox has had a lot of trouble getting drag and drop of files to work across systems, in part because it is different for KDE and Gnome and so on. If you get it working, there is no guarantee that the next release of Linux won't break it again. Even if you accept the default Gnome desktop that comes default with your preferred distribution, if the Gnome drag and drop is broken and the KDE drag and drop works, then you may want to install just the KDE File Management utility (Dolphin). It will drag along 100 megabytes of KDE lib files, but then you have two file managers and can drag and drop files to whichever one works.
Virtual USB Stick
Even if Eclipse is not automatically installed in your distribution, you can find it in the Software tool. It is almost always one or two releases (years) out of date and generally you don't want to run something that old. However, if you do choose to install it, there is some directory where the package manager tool (yum or apt-get) wants to install that particular program. Feel free to use the standard tools to install Eclipse or Java or JBoss where the distribution wants to put them.
The Sandbox comes with its own copy of everything, and it puts that stuff somewhere that no distribution would normally install Java or Eclipse. It puts them where a Linux system mounts CDs and USB Sticks (the /media directory). In that sense, the Sandbox puts all its files on a "virtual USB stick" although actually it looks to the VM like a small additional hard disk. This has two advantages. First, the Sandbox cannot conflict with any OS convention for where stuff is supposed to go. Second, this is a more natural way to arrange things if you want to work with the Sandbox files for Shibboleth, then "eject" the disk with those files and mount the disk with Sandbox files for IIQ.
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.
This way we avoid the eternal argument between /opt and /usr/local and other places where different people believe stuff should go.
One from Column A
Generally speaking the Sandbox VM environment involves choosing two separate components.
...
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 machineIf you have installed a J2EE server in the OS, then you have to stop it before starting JBoss under Eclipse or else you have to configure the Sandbox JBoss to use a different port that the 8080 default.
Of course, if you have a version of the Sandbox configured to work on both CAS and Netid (because they interact) and CAS runs on JBoss and Netid runs on Tomcat then you may have to configure two port numbers anyway. You just don't want the OS servers adding to the complexity.
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 it is the userid number that is stored in the SandboxData disk directory as the owner of all the directories in every SandboxData diskdirectoriesand files. The Sandbox OS is typically configured to log this userid in when you boot the VM. Typically the developer "casdev" 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 themin DEV, but that is typically soon enough to deal with them.
Because it is 1001 and not "casdev" that is used in all Linux rules, it would be fairly simple to rename "casdev" to a different name if you object to it. Just keep the 1001 number.
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.
Typically applications are debugged without SSL even if they run SSL in production.
Some applications have a custom log4j.xml or Spring configuration XML that references a cache directory or a file path explicitly. In this one type of case it is probably better to arrange the operating system and Sandbox so that the same file path can be used in development and production. Therefore, no matter what version of the OS you use, you will need to make "Sandbox OS can be Fedora or Ubuntu, but it can also be Windows. Java is system independent and all the tools (Eclipse, JBoss, Maven) are written in Java. You can develop CAS in Windows and then deploy it to production Linux servers and everything works.
Unfortunately, the SandboxData disk cannot be moved between Linux and Windows. While Java can be stored in the same directory on the disk for both systems, the Java executable is either a Linux program or a java.exe Windows program. Eclipse also inserts the disk letter when it configures an external file in Windows, while disk letters do not exist in Linux. So there have to be separate SandboxData images for Linux and Windows even though the component (Java, Eclipse, JBoss, or Maven) is in the same relative directory on each image.
Misc
CAS, Shibboleth, and Netid are examples of programs that run under SSL in production but run normal HTTP on port 8080 during development in the Sandbox.
Some files have to have explict fully qualified path names to a log, cache, or configuration directory. The Shibboleth WAR needs to know where /usr/local/shibboleth-idp is, and the log4j.xml file has to point to the /var/log/jbossas/standalone directory. You have two choices. You can use the standard OS file (strongly recommended for /var/log/jbossas/standalone" (or R) and on Windows you can create the C:\var\log\jbossas\standalone in Windows) writable and typically owned by the casdev useridstandaone directory. Alternately you can create symlinks in the system that redirect the path to somewhere in the SandboxData disk. Remember, the the casdev user has to have write access to such directories.
Sandbox is not Production
...