Building Windows Installers using Wix4

Owned by Rod Widdowson
Last updated: Apr 14, 2024
4 min read

Two windows installers are built to support Windows users.

  1. The IDP installer is a thin shim on top of the standard installer

    1. It unpacks the distribution into ProgramData

    2. It collects some configuration information and captures it to properties files

    3. In runs the standard installer using Property Driven Installation

  2. The Jetty installed deploys three subsystems

    1. A specific version of Jetty

    2. Procrun (a windows executable which allows java programs to be run as a “Service” (Windows speak for a daemon)

    3. A version of jetty base for Windows targetted at the IdP installation

Both of these can be build using WiX4 which in turn is invoked as part of a standard maven run (on suitable configured) Windows Machine. These pages describe how to build a release of these installers

Prerequisites (one-off)

The Windows machine you will use to do the build Installation box must have the following installed

  • Java JDK version 17 or later

    • Ensure that JAVA_HOME is set correctly

  • Maven

  • Git

  • A recent version of the .NET SDK

  • An appropriate settings.xml

Building a Release of the IdP installer

The install requires the idp-distribution zip file for the release and so the build can be done any time after it is available in Nexus.

Checkout the Release tag

git checkout "tag"

Check the msi Version

The msi.version property is the version that the msi file will carry. It is separate from the project.version because

  • It must be strictly numeric

  • It has a final digit (to allow multiple installer releases for the same IdP release). We usually use ‘99’ to mean “SNAPSHOT”.

At the time of release the version should match the project version with an appropriate 4th digit. If you need to edit it you will need to push a tag for the changed file.

Build the msi file

This is done using maven, on an appropriate windows machine in the idp-msi file

mvn clean install -f idp-msi

Sign and deploy the msi file

Use the maven sign-and-deploy plugin. The following is an untested example

ssh -L 1581:127.0.0.1:1581 -N build.shibboleth.net -f REM or use Putty set VERSION=5.1.5 set NEXUS_URL=http://127.0.0.1:1581/nexus/content/repositories/releases set REPO_ID=release SET CL1=mvn -Dmaven.repo.local=%MAVEN_REPO% gpg:sign-and-deploy-file -Durl=%NEXUS_URL% -DrepositoryId=%REPO_ID% SET CL2=-Dfile=shibboleth-identity-provider-%VERSION%-x64.msi -DgroupId=net.shibboleth.idp -DartifactId=idp-msi SET CL3=-Dversion=%VERSION% -DgeneratePom=false -Dclassifier=msi Set SIGN_AND_DEPLOY=%CL1% %CL2% %CL3% %SIGN_AND_DEPLOY%

Building a Release of the Jetty Base installer

There are two parts to releasing the jetty-base installer

  • Updating the jetty-base to reflect any changes in jetty

  • Building and publishing the msi file

Updating Jetty Base

The following is for a minor version change. Major version changes usually involved new contents and potentially manipulation of the idp.ini file (the only user configurable part of this install.

The following is for Jetty11

Preparation

Checkout the source of the relevant jetty version

Update the pom to reflect the jettt and procrun versions

Logback and SLF4J Version

The versions are specified in the top level pom file of the jetty project

This changes have to be mirrored in the pom file for the jetty base project and the src/main/resources/jetty-base/start.d.dist/idp-system.ini file

etc/jetty-ssl-context.xml

The is the most complex change and potentially the most fragile.  Charges are needed if either of these two files have changed in Jetty

  • jetty-server/src/main/config/etc/jetty-ssl-context.xml 

  • jetty-util/src/main/java/org/eclipse/jetty/util/ssl/SslContextFactory.java

You can check this with a command like this

The explicit changes are:

 

Deconstructed this change is

  • Remove the prefixing of KeyStorePath with ${Jetty.base},this  allows absolute paths to be used.  Procrun is setup to allow relative paths to use this shortcut.

  • Remove the explicit setting of 5 bean properties, allowing the Java defaults to take over..  These can be checked in jetty-util\src\main\java\org\eclipse\jetty\util\ssl\SslContextFactory.java

    • KeyManagerPassword This is used in getKeyManagers().  Having it not set  means it defaults to the KeyStorePassword

    • TrustStore reading the loadTrustStore will show that if these three properties are not set then the keystore is used.

With Jetty12 we will try to get around these issues

Building the Jetty-Base Installer

First set the revision (4th digit) of the installer version in the property file. This is usually 0, but if another version of the installer for the same jetty versio is required it should be adjusted

Checkout and Test Build

Smoke Test the installer.

Perform the release

  • Edit pom.xml to remove SNAPSHOT from versions.

  • Tag

  • Edit pom.xml to change the the version, adding -SNAPSHOT Make sure that there is alignment between the version and the version properties

  • Commit

Build the release version

Commit the work

Push to nexus using the gpg:sign-and-deploy-file plugin. For

Push changes to git