Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

The CAS Server is written in Java and is distributed in source form as a package of Maven projects zipped up into a single file. Unzipped, there is an outer "parent" directory that is also a Maven "parent" project. Each subdirectory is also a Maven sub-project to build a particular component of the CAS server. The parent project establishes global parameters for all the internal subprojects. It determines, for example, which specific version of Spring or log4j is going to be usedthat all the code will use Spring 3.1.1 and log4j 1.2.15, so all the subprojects are complied using a specific version of every library (since they all have to run sharing that version)against the libraries they will share at runtime. The parent project also determines the order in which the subprojects are built, so that each JAR file is complied before any project that references and depends on it. The last projects run build the actual WAR file that is deployed to the Web server to run CAS.

Yale adds several new Yale specific subprojects to the vanilla Apereo Maven source project directory tree. Some of the projects create JAR files that add specific functions to CAS. The final project builds the actual WAR file that is deployed to JBoss to run the CAS Server at Yale. No changes are made to the Apereo code unless there is a bug that needs to be fixed immediately.

Normally there is some physical separation between the "vendor" distribution of source and the "local" customizations, but It is a bit strange to check a large block of vendor source into a Yale Subversion directory that is supposed to contain Yale customizations. If there is a better way to handle this code, we can certainly adopt it. However, the Apereo CAS project uses Git as a source control system, while the Yale project management conventions still use Subversion. So to get Apereo code into the Yale Subversion system you have to migrate it across source management systems and probably lose the history data during the migration. Since we don't actually change the vanilla code, this is not a problem. If you want to track the history of a vanilla Apereo source file, use a Git client and get the history from Git. Storing the files in subversion is simply an alternative to unzipping it. The Yale Subversion directory is simply a copy of the source downloaded from the apereo.org web site.most convenient Eclipse workspace project that one can use to do CAS development based on a particular release of CAS from Apereo.

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 distribution for that release and generally you (either download the zip file or check it out from Git) and then copy the Yale added subdirectories from the old release project to the new release project and change the pom.xml file in the new parent to execute the projects you want to build. Copying the Yale files from one project to another will lose Yale history, but Yale doesn't change CAS code except every four years or so. If you have been running a version of the code for 4 years without modifications, then the day to day history of the old development project is no longer important.

Some might suggest that the Apereo code be kept in one project tree and the Yale code be kept in a different tree. However, the original Apereo project was designed to work with a single parent and subdirectories, and we decided not to try and change that design. Besides, if all the source from Apereo and Yale is available in your Eclipse project workspace, then all the tools to search for references to a field or during debugging to step into a subroutine automatically work correctly. It is not hard to remember not to change non-Yale code without a good reason, and then to document if you make such a change so people know that this is an issue if we move to a new release of the Apereo base.

...