...
Because Yale wrote CAS Versions 1 and 2, Apereo/JASIG numbering starts with Version 3. We know that the Apereo numbering won't go backwards, so any cas.war file with a Version number less than 3 is safe from collision. The Yale WAR file generated by the Overlay project, and all the Yale internal CAS projects are assigned Versions such as 1.1.2. An actual CAS artifact that might be installed into production will be store in Artifactory as https://repository.its.yale.edu/maven2/libs-releases-local/edu/yale/its/cas/cas-server-war/1.1.1/cas-server-war-1.1.1.war.
...
Version Numbers and Project Structure
CAS development at Yale could be separated into one project with vanilla Apereo source and one project with Yale additions and modifications. That keeps things cleanly separated if Yale was never going to make any changes.However, CAS is not really distributed as a bunch of equal projects. The cas-server-core project is 95% (or more) of the source and all the other projects are relatively small. There are always changes that we make to cas-server-core during development, although some of these changes are just for testing or exploration. In other cases there are CAS bugs, or simply differences of opinion about how CAS should work. Where possible, Yale will take a CAS core source file, generate a Yale named version of the same code, and put it in the Java source section of the WAR Overlay project. Therefore, at least during development the idea of a "pristine" Apereo source is unreasonableonly requires Maven projects to build the Yale added JARs (notably the cas-server-expired-password-change and the cas-server-support-CushyTicketRegistry projects) and the WAR Overlay project (cas-server-yale-webapp). There is no need to recompile Apereo projects if we are not going to change them. The WAR Overlay project has <dependency> statements with <version> values that select specific Apereo artifacts. These artifacts do not have to be created at Yale, but could be downloaded from the network like any other JAR library. This even extends to the base cas-server-webapp WAR file. If the WAR Overlay references Version 3.5.3 of cas-server-webapp, then it will start with the vanilla Apereo WAR template downloaded from apereo.org. This single project (the cas-server-yale-webapp project) builds the version of CAS that is ultimately installed and run at Yale. So if you want to know what is actually being used (vanilla Apereo code or some Yale modification) looking at the POM file in cas-server-yale-weapp is the authoritative source of information.
However, Yale does occasionally need to compile and perhaps modify Apereo source. Sometimes these changes are exploratory. Sometimes they help us debug a problem. Sometimes they fix an error that is important to Yale. For whatever reason this code gets compiled, it is critical that no Yale modified version of an Apereo project ever be created with the same Version number as the corresponding vanilla Apereo module. If that happens, then there are two versions of the same JAR file with the same name. One is vanilla code and one is Yale modified code, and once the two get into the Yale system there will be no way to know which you have in any given context.
So even if there is absolutely no intent to change Apereo code, or to use anything other than a Vanilla Apereo library, the first step when working with a new release of CAS from Apereo is to create a Yale base version number for this generation of Yale development and to make sure that any Yale compilation of any Apereo source use the Yale <version> value and not the Apereo vanilla value. Generally speaking, the Yale convention is to increment the middle dotted number (1.x.0) for each iteration of CAS development, and we do not install every CAS version. So Yale version 1.1.x corresponds to the Apereo CAS 3.5.y versions, and Yale 1.2.x corresponds to Apereo 4.0.0. Generally you have to change the version number in the parent project POM, but then you also have to change the <parent> version number in all the subprojects.
Now every time Yale compiles an Apereo project the resulting generated JAR will have the current Yale project number. That JAR will go into the local Maven Repository on the Sandbox machine with the Yale version number (say 1.1.4-SNAPSHOT) and if the source gets checked into Maven and you run the Jenkins Build job then a JAR file with the Yale Version number (say 1.1.4) will be uploaded to the Yale Artifactory network server. However, the Artifactory server will also have the vanilla Apereo version of the same file with the original version number (say 3.5.3). Just because we compiled our own copy of cas-server-core and uploaded it to Artifactory doesn't mean that that JAR file will eventually end up in production. If the cas-server-yale-webapp project calls for version 3.5.3 then it is the vanilla JAR that gets deployed to DEV, TEST, and PROD CAS.
However, if a Yale modified version of the source was every checked into SVN with the Apereo version number and was then built by the Jenkins Build job, then the Yale compiled version would replace the Apereo vanilla version on the Artifactory server and you would lose the ability to distinguish vanilla from Yale modified. It is not a problem if, during the initial exploration of a new release of CAS, you compile Apereo source on a sandbox machine. That just changes the local Maven Repository, and you can always clean it up later by deleting that subdirectory tree in the repository and rebuilding it. You just have to replace Apereo with Yale version numbers on the source before the first Jenkins Build job.
During development, we may make changes to vanilla CAS source to see how something works or to track down a problem. Those changes will be abandoned in the final deployment. The only time we deploy a Yale modified version of a standard Apereo JAR file is if there is a critical Yale bug fix that we need for reliability, or if we have a serious difference of opinion with the Apereo source committers.
Some examples of differences of opinion or bugs:
...
Once you start to consider changing Apereo code, then it is inconvenient to maintain two separate projects. For one thing, you need two separate Jenkins build jobs, one for each project. Then you have release numbering issues.
The alternative is to have a single project that combines both the Apereo source for a CAS release (example: 3.5.2.1) and the Yale code that has been built and tested for that CAS release (separately designated Version 1.1.x). Most of the time the Apereo source just sits there and is not used and is not compiled because it is not changed. If you need to make a modification, it is immediately available and can be compiled simply by adding or re-enabling the <module> statement for that project in the top level pom.xml file.
...