Not-Building

Whenever you save a Java source file, Eclipse compiles the source and stores the generated *.class file. The Eclipse project structure is able to test a J2EE application like CAS without ever actually building all the JAR artifacts.

Examine the cas-server-webapp project. You will notice that it has an unusual structure with additional items:
When the Eclipse Maven plugin [with the J2EE Maven plugin optional extension] created this project, it noticed that the POM declared that this was a WAR artifact. So it build an Eclipse J2EE WAR project, which has this special structure.

During project creation, the Dependencies in the POM were examined and they were divided into two groups. The ordinary library JAR artifacts were put in the Maven Dependencies list while dependencies on prior projects are broken out separately. You can see this by right clicking onthe WAR project and selecting Build Path - Configure Build Path - Libraries

This example reflects the vanilla cas-server-webapp project distributed by JA-SIG where the POM includes in its list of dependencies may external libraries, but of the previously compiled artifacts in the CAS Server source, it only includes the cas-server-core artifact. If you want to use any of the other optional project artifacts, you have to change the POM and add them to the WAR dependency list, and then the Eclipse Build Path will change to add them to the Web App Libraries as well.

What happens next depends on the particular Application Server you want to test under and the particular plugin that you use to do the testing. There are two strategies.

The Eclipse Web Tools project has a particular debugging style that works well with Tomcat. You configure the Windows - Preferences - Server - Runtime Environments to point to an instance of Tomcat. That provides a copy of the base code. However, the Eclipse J2EE support knows that you can start Tomcat with a special parameter to insert your own ClassLoader implementation. Instead of copying all the class files into Tomcat, or zipping them up to build JAR and WAR files as a normal production installation would do, Eclipse simply inserts a substitute ClassLoader into Tomcat that knows where to go in the Eclipse workspace to get the class files generated by the projects listed in the Web App Libraries list (in this case, the cas-server-core output directory and the WEB-INF/classes of the webapp directory). Whenever Tomcat needs classes, then at the point where it would normally search the WAR directory, it instead obtains them directly from Eclipse, and Eclipse searches the Web App Libraries list. This avoids having to copy all the class files before you test the application, but it means that the application only runs under Eclipse.

Of course, a much simpler strategy would be to simply build the WAR and install it in the application server, or at least to build the directory structure and copy it into the webapps subdirectory of Tomcat or the server/default/deploy directory of JBoss. Then the application server can be started using its normal directories configured in the normal way. In fact, with this strategy you can shut down Eclipse, change to the Tomcat directory, start Tomcat manually, and run the application that Eclipse installed in it.

Eclipse may use either strategy depending on the application server you choose and the type of Eclipse plugin you select to run the application server in debug mode. Either way, Eclipse maintains the ability to "hotdeploy" files. So if you edit a JSP page and save it, that immediately replaces the version of the JSP page on the application server, and even the code for classes can sometimes be changed without restarting the server (however, the rules for what can be changed and when are complex enough that you probably want to always stop and restart the server anyway).