...
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 on the 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 only one of the optional projects that actually gets included in the war is the required 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. However, if you select other optional projects to include in the configuration If you want to use any of the other optional project artifacts, you have to change the POM and add them to the POM, they will also be added to the Build Path "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 configured in the Build Path for the WAR project. That is, Tomcat get its classes directly from the Eclipse workspace without having to copy them over to some Tomcat directory.
However, this is not the only available strategy. When the ClassLoader trick will not work, or when it is desirable to copy all the class files and the webapp files into the normal deploy directory of the J2EE server, Eclipse can do that too. Then the server is started as it normally would be from its normal directories, except that it runs in debug mode.
If you are frequently editing and changing source, the Eclipse approach is faster and simpler than the Maven build, but only slightly solist. 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).