...
Yale and JASIG use Eclipse as the IDE. The most current version of Eclipse works best. Start with the J2EE package of Eclipse. Use the Help - Eclipse Marketplace tool to add support for Subversion (use Subversive), Maven (M2E), AspectJ (AJDT), and add SVN and Maven support.the add the M2E-AspectJ support from Add Software source http://dist.springsource.org/release/AJDT/configurator/. You are certainly free to add other Eclipse features for other development.
Check Out and Build the Project
...
- JSP, HTML, XML, XHTML, and JavaScript files may report errors because Eclipse is trying to validate syntax without having everything it needs to do the validation properly, or because some files are fragmentary and have to be assembled from pieces before they are well formed.
- You can get Build Path error if you only have a JDK 1.7 or later installed on your machine, because the Maven template used to translate POM files automatically defaults to 1.6 or earlier. CAS should run fine on later versions of Java, or you can manually change each generated project to use 1.7 as the compiler level.
- There will be a Maven problem reported because CAS uses the Maven Aspectj plugin during its build, but the Eclipse simulation of Maven does not support that particular function. You can ignore this message because a real Maven build will be run to create the real artifacts.
Generally, there should only be Warning level Generally, there should only be Warning level Java messages.
Before the import, there was only the "cas-server" project (and the installer). The import creates an Eclipse "shadow project" (my name) for every subdirectory under cas-server that is needed. These shadow projects are Eclipse entities built from the Maven POM files. They contain Eclipse configuration and option elements (what Eclipse thinks of as the project and Build Path). What these shadow projects don't have are real source files. They contain configuration pointers the real source files in the subdirectories of the cas-server project. As you open and look at these projects, they will appear to have source. However, this source will be structured as Java Packages and Java Classes and Java Resources. This is a logical representation in Java and WAR terms of the actual source files that remain as subdirectories of the cas-source directory.
...
Interactive and Batch Modes
Eclipse wants to make things easier than they can really be. It wants to extract information from the Maven POM but then to compile the source and build the "WAR" itself. However, it doesn't really want to build a WAR file and then copy it over to the Tomcat or JBoss server. So it has some special logic to "hack" the configuration of Tomcat and JBoss servers so that they run with an imaginary WAR that doesn't really exist in their directories but is being simulated by Eclipse.
This works fine for Hello World and maybe the next five Web applications you write, but pretty soon you want to do something that Eclipse is not ready to simulate. Alternately, you may want to use some Maven feature that Eclipse cannot duplicate.
At this point what you really want to do is to run not the integrated simulation of Maven and JBoss function built into Eclipse, but rather you want to run Real Maven and Real JBoss. You can do that in Eclipse, but for sanity you have to realize explicitly that you are rejecting the "simplified" environment that Eclipse tried to create for you. You also have to understand what Eclipse just tried to do, what it accomplished, and how to do the rest yourself.
Eclipse reads the Maven POM file and creates an Eclipse project that tries to do the same thing. The Eclipse compiler can use roughly the same options to compile the same source library to the same target directory of class files. The Eclipse Maven support can turn the dependencies in the POM file into an Eclipse .classpath file that gets the right Java library files from the local Maven (.m2) repository directory. However, Maven has support for additional operations controlled by "plugin" elements of the POM file, and Eclipse does not support these extra steps.
...
"Everything should be made as simple as possible, but no simpler" (attributed to Albert Einstein)
It may reasonably be said that Eclipse tries to make J2EE development simpler than is reasonably possible. Eclipse is almost successful, close enough so that it is quite usable as long as you realize what cannot possibly be made to work exactly right.
The Maven POM contains declarations that drive a Java compiler running under Maven to compile all the source, and then it builds JAR, WAR, and EAR files. The M2E support for Maven inside Eclipse tries to understand the POM file and to create a set of Eclipse project configurations that do exactly the same thing. Typically this works for the compile part, and therefore it works for all the good things that Eclipse does about autocomplete of source and autocorrect of errors.
However, Eclipse is not really in the business of building actual JAR, WAR, or EAR files. Instead, it tries to do something "better". The problem you would have if you were doing simple Java WAR file development is that when you make a change to an HTML or JSP file and press save, then the file is saved to the Eclipse workspace. However, even if the Web server you are using supports "hot deploy", getting this changed file over to the server would normally require a separate deploy step.
So Eclipse J2EE support was designed to "hack" all the standard Web application servers. It has special code for Tomcat or JBoss to "deploy" to the server a virtual EAR or WAR. There is no actual EAR or WAR file artifact. Instead, the server is run in a special mode with Eclipse configuration modifications that make it think there is an EAR or WAR directory, when in fact the directory is being simulated by Eclipse using the files in the Eclipse project in the workspace. So in this mode, when you save an HTML page to the workspace, you are logically, though not physically, also saving it to the virtual WAR in the server. Tomcat or JBoss see the file as having been updated, so they use the new version of the file just as if it had been hot deployed to their real webapp or deploy directory.
This is one hack too far for any really complicated application. The problem is that the hacked Tomcat or JBoss configuration is not the real Tomcat or JBoss configuration that would be run if the server ran normally, and the difference may be important if you have other configuration changes you need to make in order for your program to run correctly.
So instead of using this "interactive" compile and deploy technology, the safer alternative is to use the "batch" approach of running a real "mvn install" to create the real WAR or EAR artifact, then a real install/deploy to copy the artifact to the regular deploy directory of the regular server. Then you can run Tomcat or JBoss under Eclipse for debugging using an Eclipse plugin like Mongrel (for Tomcat) or JBoss Tools.
The advantage of the "batch" approach is that you are guaranteed to get a 100% exact duplicate behavior as you will get later on when you run the Yale Jenkins jobs to compile and install the application onto the test or production servers. Eclipse does a pretty good job of doing almost exactly the same thing that Maven will do, but it is not worth several days of debugging to finally discover that almost the same thing is not quite as good as exactly the same thing.
Eclipse recompiles each Java source file when you save it. Since the Eclipse project was created from the Maven POM, it compiles the same source directories that Maven uses and it puts the class files in the same place Maven puts files when it compiles them. By default, Maven only recompiles a program if the source is newer than the class file. So normally, the Eclipse compiler always "wins" the race and all the source files in the project will have been compiled by Eclipse. If there is strange behavior and you believe it is due to differences in the Eclipse and Maven compile options, you can recompile everything by adding "clean" to the Maven goals.
...