Update build branches

• Build order for the projects is at the top of the build instructions here: https://github.com/KualiCo/kc/blob/master/README.md
  • The typical order is schemaspy > kc-rice > kc-api > kc-s2sgen
• For each project in order, do the following:
  • Open Git Bash in the project folder
  • git remote -v
    • Verify that the KualiCo repo is added as a remote, e.g. https://github.com/KualiCo/kc-s2sgen
  • git checkout master
  • git fetch github
    • This will pull down all new tags from the KualiCo repo
  • Check the KC master POM file to find the current required version number for each project (it's not always the latest version needed): https://github.com/KualiCo/kc/blob/master/pom.xml
  • git checkout <tag for project version that matches the KC POM file>
    • e.g. git checkout coeus-s2sgen-1901.0001
  • Add the tag to the RAS Current Build Branches wiki page: RAS Current Build Branches
  • Build the project:
    • mvn clean install -Dgrm.off=true
  • Push the tags up to the Tufts GitLab repo:
    • git push --tags
• Repeat these steps for each dependent project.
• Once all dependent projects have been built, the 'kc' project should be built next. Follow the same steps as above to fetch the new tags and checkout the most recent release tag. However, instead of doing a simple 'mvn clean install', use the following commands to build the project:
  • export VCTargetsPath="C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120"
  • mvn clean compile source:jar javadoc:jar install -Dgrm.off=true -P oracle

Update kc-custom projects

Now we need to merge any Kuali changes into the Tufts custom classes and make any further changes that are necessary to maintain compatibility, or revert changes that clash with our customizations that we want to keep the custom behavior for.

• Create a second git directory which will contain the previous versions of each project. Clone the 'kc', 'kc-s2sgen', and 'kc-rice' projects into this folder, and checkout the previous branch for each project (the versions we were coming from in the steps above, not the version we updated to).
• Also clone the current kc-custom project into this folder. (Not strictly necessary, since we'll be working from the copy in the regular git folder, but it's useful to have a 'before' snapshot for troubleshooting or debugging.)
• We currently have four custom projects to update:
  • rice-impl-custom
  • coeus-s2sgen-impl-custom
  • coeus-impl-custom
  • coeus-webapp-custom
  The rice and s2sgen projects only have a couple of custom files each, so let's update those manually first.

• I find it easiest to open up 4 explorer windows in a grid, showing the old base/custom and new base/custom projects, like so:
  
• Now, for each file in the "new custom" project, use a diff tool like WinMerge to do two comparisons:
  • Compare the "old base" version of that file to the "new base" version, to see what changes Kuali has made to the file.
  • Compare the "old base" version to the "old custom" version, to see what customizations Tufts has made to the file.
• Then, update the "new custom" version of the file to accommodate both sets of changes. 
  • In most cases, the Kuali changes and the Tufts changes won't overlap. For these, just merge the new Kuali changes into the custom file. (If there are a lot of Kuali changes, it may be easier to just copy the new Kuali version over into the kc-custom project and re-add the Tufts changes.)
  • In cases where the Kuali changes do  overlap with the Tufts changes, you'll need to make a judgement call about how to merge the two files. If Kuali is making changes to a feature/function that we specifically overwrote with our own logic, we may want to simply keep our code – though it may still require updates if Kuali is changing classes/functions that are used by our custom code. Conversely, if Kuali is making a major overhaul to a class, it might be worth re-examining our customizations to see if they still make sense to keep. 
• Maven pom.xml files are a special case, since these are usually completely re-written for the Tufts custom projects. Usually, all you'll need to do to the pom file is update the version number near the top to match the new Kuali version. 
• Once the pom.xml and all of the java/resource files have been updated, test out the build with the command "mvn clean package -Dgrm.off=true" to ensure there are no compile errors, then move onto the next project.