Customizing the IPT v 2.0.5

In a much older post Peter Desmet, the first Biodiversity Informatics Manager for Canadensys, described how he adjusted the look & feel of our default installation of GBIF’s Integrated Publishing Toolkit (IPT), v. 2.0.3. With a few adjustments to some key files such as a stylesheet and a handful of templates, our IPT repository resembled all our other web pages. Peter also had a few scripts to apply the changes and to roll them back in the event he wished to make additional changes.

Today we upgraded our IPT to v. 2.0.5, GBIF’s latest version of their excellent software package that permits the packaging and publishing of occurrence and checklist data into Darwin Core Archive files. The upgrade meant we had to reapply Peter’s scripts, or some variant of them. Instead of using Peter’s method however, we tried our hand at something different: a patch file. Although a bit overkill, we put our patch file on GitHub so you can see what it looks like. Here’s how we did it:

  1. Installed GBIF’s IPT on a laptop from the WAR file here
  2. Navigated to the Tomcat directory; because I use homebrew on my Mac, mine is


  3. Prepare a naked git repository

    $ git init && git add . && git commit -m "I love vanilla IPT 2.0.5"

  4. Created a branch & started hacking

    $ git checkout -b canadensys_chocolate

  5. Committed to the local branch and rebased/squashed commits as necessary
  6. Created the patch

    $ git format-patch master --stdout > canadensys_ipt_2.0.5.patch

  7. Applied the patch on a different machine*

    $ patch -p1 < canadensys_ipt_2.0.5.patch

  8. Or reverted it

    $ patch -p1 -R < canadensys_ipt_2.0.5.patch

The effect is much the same as what Peter first developed but the advantage of the above approach is that we never have to remember what adjustments we made to what file in the IPT and when it comes time to applying the changes on a production machine, there's just one file we need to use (plus any binaries if needed). Peter's approach can still be found as a v. 2.0.3 release tag on our GitHub project.

*The better option would be to use git itself to apply a patch, but this never seemed to work without issue for us, so we used the old-school patch method.