CAS source and configuration files are stored in the Yale Subversion repository at https://svn.its.yale.edu/repos/cas. If you are updating the current release, everything you need will be there. If you are upgrading to a new release of CAS, you need to obtain a copy of that release from JASIG. CAS releases are distributed as a zip file, but they are also checked into Git. Unless you are contributing updates back to JASIG, there is no need to access Git, but there is no problem using it as the source if you feel comfortable with that.
CAS development has traditionally used the Eclipse IDE. Choose the J2EE development configuration because it will come with support for WAR projects. It has been necessary to add support for Subversion and Maven to the base J2EE distribution, and it is recommended that you install the JBoss tools, at least the tool that starts and stops the JBoss server.
An Eclipse project is a directory with a .project and .classpath file. A Maven project is a directory with a pom.xml. If you check out a directory that has the Eclipse project files, then Eclipse will automatically know what to do. If you check out (or download from JASIG) a directory tree with Maven project files but no Eclipse files, then the M2E Maven plugin for Eclipse will examine the POM files and generate the necessary Eclipse project. Check out the directory into the Eclipse workspace, then do a File - Import - Existing Maven Projects. M2E will create a normal Java Eclipse project for a Maven JAR project, and it will create a J2EE Web Eclipse project for a Maven WAR project.
M2E does not have support for all the Maven plugins available, and CAS typically uses AspectJ and some other features. You can ignore the Maven messages about plugins that M2E doesn't handle because you will be running a real Maven batch build to create CAS rather than relying on the default compilation done by Eclipse every time you save a file.
M2E uses templates to create each type of Eclipse project. The template for a WAR project is configured for Java 1.6. If you want to use 1.7, you may have to change the project configuration manually after the default project is generatedfor Git and the Zip file will do fine.
Unless specifically identified in the Release Notes and documentation, every directory (subproject) from JASIG is unmodified. There are no Yale changes to reconcile from release to release. Yale may have checked in the previous JASIG release source, but that is simply because there is no way to do the usual "vendor branch" reconciliation in SVN when your vendor uses Git. It might have been more obvious if we simply depended on the JASIG artifacts and did not even include any JASIG source. However, we do not promise to preserve the version number of dependent libraries, and therefore the source may need to be recompiled with the selected JAR libraries even if the source itself was not changed.
Yale and JASIG use Eclipse as the IDE. The most current version of Eclipse works best. The Eclipse project setting files will probably be checked into the Yale SVN. Eclipse project files can be mostly recreated from the Maven POM, but that regenerates standard options from the Maven-Eclipse support templates. Checked in .project files may have Eclipse options that are tweaked for simplified development, but they are not required for development.
Eclipse normally likes to run Servers (Tomcat, JBoss, etc.) in a special environment it sets up for debugging. This is OK for Hello World, but it really doesn't work for complex projects. The JBoss Tools for Eclipse include a plugin that starts and stops the JBoss server from Eclipse, but runs JBoss with its standard configuration and environment. You can start JBoss in debug mode and control it from Eclipse.
Eclipse reads the Maven POM file and creates an Eclipse project that tries to do the same thing. However, the Eclipse build is not a real Maven build. 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. That would be fine if all you are doing is Java compiles. However, Maven has support for additional operations controlled by "plugin" elements of the POM file, and Eclipse does not support these extra steps. The Eclipse Maven support is good enough to get all the source files properly defined in Eclipse with, for the most part, no little red error X marks for missing include files. You can edit the source and use autocomplete and autocorrect. However, the real JASIG build process includes AspectJ and some other Maven plugins that Eclipse does not simulate. So the first time you generate a new project from vanilla source, you may have to run a "mvn install" in batch mode to run all of the real build steps, then refresh the Eclipse project (both by doing an F5 file refresh but also by doing a Maven POM refresh) to get rid of an initial bunch of red X error messages for missing stuff that Maven generates first time it is run.
If you are migrating to a new release of JASIG CAS, then the old Eclipse project files may not be useful. Start from scratch and create a new Eclipse project out of the Maven POM. The first step is to create an Eclipse "naked project" that contains only the JASIG "cas-source" directory. It is naked because you did not ask for a Java project and so it has no Java or J2EE nature to it. It is just a bunch of directories in an Eclipse project. Now do a File - Import - Existing Maven Projects. Eclipse will list the parent cas-server project and all of its subprojects. You can select all of them or just the projects you really intend to use. The Eclipse Maven support plugin (called "M2E") will identify from each POM whether a Maven project generates a JAR, WAR, or EAR (although today we have no EAR projects). It will assign a Java nature and set up all the compiler options. However, it uses template files with default options for each type of project, so you may start with projects configured for Java 1.6 and need to change that option to 1.7 if that is the version of Java you intend to use. At this point, comparing options from the old project with the new projects may be helpful.
Remember, the "interactive" Eclipse behavior and the Eclipse compile (which occurs automatically every time you save a file) is driven by the .project, .classpath, and .settings Eclipse files. However, the Maven build is driven by the POM file. M2E tries to reconcile the two, or at least set them up so they do not conflict. However, it is not guaranteed. If you are not foolish enough to simply assume that they work correctly because the magic is always done right, then you manually fix any discrepancies. Remember, by default Maven running in the Eclipse directory (whether run from the command line or from the Eclipse menus) will not recompile a source file that has already been compiled since the last time it was edited, and Eclipse recompiles files when it saves them. So generally the Eclipse compiler wins the race on your desktop. However, when deploying to DEV, TEST, PROD there is no Eclipse and Maven does everything itself. So when in doubt, do a "mvn clean install" on your desktop and force Maven to compile everything itself if you discover quirks during testing that might be caused by different options used in the interactive and batch Java compile.
When CAS is built and then deployed to DEV, TEST, or PROD, the Jenkins Build job checks the source out of Subversion, runs Maven to build the artifacts, and then checks the artifacts into the Yale Artifactory repository server. The Install job then checks the WAR artifact out of Artifactory and copies it to the JBoss deploy directory.
...