...
The Sandbox is a friendly environment for developers to edit, compile, build, and debug the application. It is specifically not designed to duplicate the runtime configuration of production. For that you have DEV and TEST.
That's not how I do it!
The Sandbox does not try to run the best operating system. It does not put applications in the correct directories. The problem is that no two people have the same opinion about how to arrange a system. The Sandbox provides a good default for the large number of people who don't care, but it allows you to do as much customization as you insist on doing. You can use Ubuntu, Fedora, Centos, Windows, or even Mac as the runtime operating system. No matter what version of Java or JBoss you prefer, you have to run the release that the application uses in production.
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 image.
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 APIIf 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. Since the production systems don't have such things, the Sandbox cannot depend on whether you choose Gnome or KDE as your desktop, or Ubuntu, Fedora, or Centos as your Linux, and while Yale standardizes on Eclipse because it is adequate and free you can certainly try something else.
You make a mistake if you do not use the same version of Java and JBoss that your application runs in production. Beyond that, there is flexibility.
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 image.
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. The Sandbox disk image contains one or more Java Runtimes, JBoss servers, Eclipse IDEs, but they are always in the same relative location. Typically you only need one release of Java for one application, but when you are developing a version upgrade that will also be accompanied by an upgrade of Java on the production systems, then the Sandbox may have both the new and the old Java installed.
In the operating system, the default version of Java is controlled by system commands. In the Sandbox, it is controlled by the configuration of Java versions in Eclipse.
Ubuntu and Red Hat put the same component or application in different directories, and if you go to the original developer you will get an entirely different layout. Different applications at Yale run on different releases of Java, and it makes no sense to change the default version of Java in the system let alone care what directory Java is installed into. So the SanboxData disk contains its own versions of Java. When you start Eclipse, the version of Java can be selected by the eclipse.ini file in the Eclipse directory. Then once Eclipse is running it has one or more Java Runtimes configured both as to version and location on disk. Because the Sandbox developer starts Eclipse and never leaves it, the location and identity of the default Java on the OS disk doesn't matter.
...