...
- 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
...
rice-impl-custom and coeus-s2sgen-impl-custom
- 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 in the new rice-impl-custom project 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.coeus-s2sgen-impl-custom project and do the same thing.