Scope

This document describes how to set up a patch file to patch the JOC Cockpit.

This article replaces Patching - Create Patches for JOC Cockpit (DEPRECATED).

Naming convention

File Extension of the Patch File

  • The patch file has to be a zip file.
  • Only files with the extension zip will be picked up by the patch-executor.
    • Applications to create a zip file are available for most Operating Systems
    • Files with file extension tgz and tar.gz are available only for linux Operating Systems and are rarely available on Microsoft Operating Systems

Naming of the Patch File

  • We have only ONE patch file for all patches of per release. The naming structure of the patch file has to look like this:
                                         joc.[VERSION]-patch[PATCH_VERSION].war
    where the date has the format YYYYMMdd
  • Example: joc.1.13.3-patch1.war


Structure of the Patch File

  • The patch file has to have the same structure as the joc.war file for all front end stuff i.e. for all files outside the WEB-INF folder.
  • The WEB-INF folder contains only one jar and the version.json
    • ./lib/_patch-<releaseVersion>.jar (the leading underline is important to provide that this jar is loaded at first.
    • ./classes/version.json

_patch-<releaseVersion>.jar

  • This jar contains only class files which were changed because of an issue.
  • All changed class files based on the Git-Tag of the release which is patched.
  • For this a new branch with the name "patch-<releaseVersion>" is created starting on the Git-Tag of the release if it doesn't already exist.
    • Select Git-Tag (e.g. v1.13.3) in Git Extensions
    • Click on "Create New Branch" of the context menu
    • Type the name in the following dialog and push the button.
  • If the patch branch already exist then further changes continue in the branch
  • A patch branch is never merged into the snapshot branch and vice versa
  • A patch branch can be merged into another patch branch
  • For a local build of the own changes it is strongly reccommended that 
    • all patch branches are checked out
    • all revisions of the Release-Git-Tag are checked out where a patch branch doesn't exist
  • Steps after local build:
    • Download current patch file from download.sos-berlin.com
    • Extract _patch-<releaseVersion>.jar
    • Add or update the class files.
    • Create _patch-<releaseVersion>.jar
  • Hint to avoid duplicate work between snapshot branch and patch branch using Git Extensions
    • checkout patch branch
    • select commit in snapshot branch where the changes are already made
    • Goto "File Tree" tab, select changed java file and use "save as" to copy the changes in the patch branch
    • In ~90% of all cases is that all what you need particularly the files were untouched since last release.

version.json

  • This file is read during the login and the "version" is logged in the JOC log.
  • This file is edited to know which exact version (including the patches) the user has.

    • The "version" contains the Jira-Tickets
    • The "date" contains the creation date of the patch file.
  • Example
    {
      "version":"1.13.3 Patch JOC-877, JOC-880, JOC-892",
      "gitHash":"188987909bb722a8b1a0bd021f51e12d0c8ae494",
      "date":"2020-02-21"
    }
  • No labels