...
Its not that you cannot solve each of these problems in a new environment. It just takes days or weeks. The Sandbox makes it all just work.
That's
...
Any single configuration requires making choices. A practical problem is that nearly everyone else has a different view about how things should be done. A single inflexible configuration won't be used by people who are sure they have a better way to do things. So the Sandbox is flexible.
You need an operating system. You can use Red Hat (the Fedora flavor if you want newest, or the CentOS version if you want to match production), or you can use Ubuntu. For that matter, you can probably use Windows.
The Sandbox permits this because Java is system independent, all the tools run the same way on all systems, and nothing has to be installed in a specific place by a standard installer. JBoss doesn't have to be in /opt, or /usr/local, or C:\Program Files. Eclipse can be unzipped anywhere you want to put it. Nothing prevents you from installing Java on your system with an RPM or apt-get or a Setup program, but that is not the version of Java the Sandbox is going to use. It will provide its own Java, Eclipse, and JBoss that will be perfectly happy coexisting with any other Java, Eclipse, or JBoss you may have already installed elsewhere. The only limit is that only one server can use port 8080, so when you run multiple servers you have to configure different port numbers.
The first attempt at a sandbox was driven by advice provided by the system administrators who create the production systems. They strongly urged us to adopt a version of the same VM they use in production. While that VM was able to run the program, it had no development tools to edit or debug. We could have used that VM just to run and remotely debug the code, but then we needed a different platform to run Eclipse. Alternately, you could upgrade the provided VM to have a full desktop environment, but now it was a substantially different environment. There may be some use for a copy of the production VM as a kind of PRE-DEV environment, but for most development the system independence of Java means you do not have to exactly duplicate OS. It is, however, important to exactly match the version of Java and JBoss or Tomcat on the target runtime.
Although we tend to use Eclipse, it is possible to use IntelliJ if you prefer. The OpenJDK version of Java is not recommended at this time, so the Oracle Java is provided.
...
not how WE do it!
Of course Ubuntu is best, or maybe Red Hat, or maybe Windows, or maybe the Mac. Everything should go in /opt, or maybe /usr/local. Java 1.6 is stable, but you must have the new features in 1.7, and of course 1.8 is current. Tomcat is much simpler and do everything with Spring, or JBoss is standard and do everything with EJBs. The user interface must be JSP, JSTL, JSF, MVC, Struts, Velocity, ...
Even if you can get everyone in Yale ITS to agree on a choice, management will then hire some consultants or offshore the next project and a new group of developers will be absolutely sure they know all the answers. You can try to force everyone to use a single solution, but they will hate it and blame it when they make things end badly.
The Sandbox will be a failure if we try to force everyone to do things in exactly one way. The purpose of the Sandbox is to avoid developers wasting days or weeks reconfiguring their systems before they can start to be productive. It provides a set of tools, but more importantly it provides a strategy to use them in a way that makes sense without tripping anyone's religious sense of the "one true way" to work.
You need an operating system. The modern Sandbox is largely independent of operating system choice. You can run it on any Linux distribution or Windows. Someone will adapt it to Apple and contribute the result, but for now we assume it is like Linux. You need a Java, but the Sandbox does not care if you believe that the Oracle Java is best or you insist on open source. Most importantly, you can install your Java and your Eclipse anywhere you want, using any RPM or installer you choose, and the Sandbox doesn't care because no matter what choice you made for the system, the Sandbox doesn't use the java or Eclipse you installed in the OS. It supplies its own second copy, and even people with very strong view about where things should go on their system don't care where a second unofficial copy of the same thing goes.
Java development uses tools written in Java, and Java is system independent. A particular Java runtime is built for a particular operating system environment because it comes with executables (java, javac) that have to be built for that OS. You can have more than one Java runtime (JRE) on your computer, and even if one of them has been installed in a system library and has been designated as the default for that system, everything in the Sandbox is by default configured to use a different JRE in the Sandbox itself and ignore the system default. In the past, the OpenJDK version of Java has had bugs, and it is generally still not recommended for production. However, for debugging the JRE probably doesn't matter (although it must match the version number under which the application will run).
Java tools don't have installers. The most important tool is Eclipse, and it is just unzipped into any directory. Then you configure everything to Eclipse. You tell it which Java runtime to use for each application or function. You configure each version of Maven, each version of JBoss. When using the Sandbox, you start Eclipse and never leave it. Everything runs under Eclipse and so operating system environments and Paths do not matter. Therefore, the Sandbox does not depend on the OS configuration.
You do need to install into the OS any services or libraries that the application requires to execute. Nominally the Netid application requires the kadmin Kerberos library to run, but it exposes a parameter and if you install it with "kadm5_activation=false" then it doesn't use that library and can even run on Windows. When a particular system service is only marginally important and can be bypassed or mocked out, this is a best practice.
More than one Web Server may be available. Shibboleth runs in production on JBoss 5, CAS on JBoss 6, and Netid on Tomcat 7. Shibboleth can run together with CAS on JBoss 6, but changing Shibboleth may be too much trouble. If more than one Web Server has to run on the same machine, then you need to dedicate different port numbers (or else bind each server exclusively to a particular Ethernet address).
Although all these applications run https:// in production, it is much easier to debug if you can run them on plain http. CAS has a parameter "cas.cookie.secure=false" that turns off the flag that requires SSL before the Cookie is written, and again this is probably a best practice for development.
Everything is configured around Eclipse. If you insist that IntelliJ is better, you can try to duplicate the configuration, but do it on your own time.
Generally speaking, everything in the Sandbox is not in the location where it would normally go in production, and generally all these directories are owned by a single development userid. The exception to this rule are directories that have to be configured in the application to point to a specific path. For example, if your log files in production have to go to /var/log/jbossas/standalone and that specific location has to be configured in several different places, then it is probably safest to use the production location for that one purpose. In Windows you can use the same configuration, although it means \var\log\jbossas\standalone on whatever the current disk letter happens to be (R: is the Sandbox convention).
The Sandbox is not, by definition, a production environment. So it generally doesn't require efficient execution. If the OpenJDK has a history of memory leaks in applications that run for months without being restarted, the server in the sandbox will get restarted several times an hour. If you run the Sandbox in a VM, it doesn't matter if you choose VirtualBox, or VMWare player, or Hyper-V to serve as the host. We are developing business applications here, and they don't depend on having 3D acceleration in the video driver or a paravirtualized LAN adapter.
Of course the simplest thing to do is to accept the defaults and all our design decisions and treat the Sandbox VM as a utility device. You pick it up, you use it, and you don't confuse working to change the Sandbox with actually getting real work done. If that isn't good enough, then try to understand the design so you leave behind something others can pick up and use.
...
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, EclipseEclipses, some Mavens, some JDBC drivers, some JBoss or Tomcat instances, and some starter Eclipse Workspacesworkspaces.
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 platforms. The format of these two disks is identical (same directories, same contents, just different executables).
...