CAS was created at Yale and Versions 1 and 2 of the CAS code were written at Yale. Version 3 was completely rewritten and was hosted by JA-SIG which has subsequently been merged with Sakai and renamed to Apereo. Any reference to JASIG and jasig.org in this documentation should be understood to now reference apereo.org.
The CAS Server is written in Java and is distributed as a set of Maven projects. There is a parent Maven project that sets the global parameters and contains subdirectories/subprojects that build components. The last subproject executed combines the results of the previous projects and builds a Java Web application (a cas.war file).
Yale tries not to change the official distributed source, but sometimes there are bugs that need to be fixed immediately. Therefore, it is a local Yale convention that even when there are no changes to the vanilla distributed code, the Yale customizations and additions are added as additional subdirectory/subprojects to the source of a release of the base Apereo code.
A copy of the CAS Server source with the additional Yale projects is always checked into Yale Subversion as https://svn.its.yale.edu/repos/cas. If you are making changes to the current release, then everything you need is there. If you intend to upgrade to a new release of the Apereo code, then you obtain a new copy of the 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. Check out the cas-server project and the installer project and follow the instructions below.
An SVN directory of CAS source begins by checking in a new JASIG release. Then the additional Yale JAR project directories are added and one Yale WAR project is added. The top level POM file will be modified to add the new Yale projects, to disable recompilation of the optional JASIG projects that we are not using, and possibly to set the Version numbers of certain standard library files that are dependencies for the JASIG and Yale source.
JASIG uses Git as a source management tool, while Yale still uses SVN. So while you are free to check out the current release with Git, you can just as easily download the zip file. Either way, the resulting code has to be checked into SVN.
Yale attempts to make very few changes to any JASIG code. By starting with a fresh JASIG release and by then merging Yale code and reapplying any Yale fixes or modifications, the SVN history will describe what has been changed in the past release and will tell you what needs to be changed to migrate to the next releasedistribution for that release and generally you copy the Yale subdirectories from the old release to the new release and change the pom.xml file in the new parent to execute the projects you want to build.
The Apereo CAS project uses Git as a source control system, while the Yale conventions still use Subversion. So whether you download a zip file of the CAS Server source from Apereo or you check the same source out using Git, you are still going to need to check all the vanilla source for each new release into Subversion. Since Yale generally does not change any vanilla source, it is not really important that Subversion regards each new vanilla source release as a brand new file. If you really want to track changes to the Apereo source that Yale does not change, use Git separately from any Yale development.
Since we are not changing the Apereo code, some might suggest that we should not bother with the Apereo source at all. Perhaps we should just work with the Yale source. You could do this, but then if you are debugging and trace into a unmodified Apereo class there is extra work to make the source code visible, and if Yale development requires that some standard third party JAR library file (for example, the Apache httpclient library) has to be upgraded from the release that Apereo uses to one or two minor releases later to provide a feature or fix a bug that Yale needs, then recompiling all the Yale and Apereo code with the same library provides greater assurance that everything will work in production.
The ReleaseNotes.html file in in the root of the cas-server project will identify the current state of new directories and any modified files. This should be a descriptive match for the physical code change history in SVN.
...
- Maven support (M2E) which appears to be standard in the latest releases.
- Subversion support (Subversive) which is not automatically included because there were several competing projects. The first time you run a Subversive window you will get a popup to install a third party (Polarion) connector from a list and you should choose the latest version of SVNKit).
- JBoss Tools (at least the JBossAS manager) which is listed in Marketplace because it comes from Red Hat.
- AJDT, the Eclipse support for AspectJ which the JASIG CAS source uses (starting with the Luna release, Eclipse realizes that CAS uses AspectJ and automatically installs this component when it processes the CAS project if you have not preinstalled it).
- The standard Maven support comes with a version of Maven 3 built into Eclipse. That is exactly right for building the CAS executable, but it is a Yale convention that the Install job that copies the WAR file over to JBoss has to run under Maven 2. So you need to download the last Maven 2.2.1 from apache.org and unzip it to a directory somewhere on your disk. Later on you will define this directory to Eclipse as a optional "Maven Installation" it can use to run jobs configured to use Maven 2 instead of the default 3.
...