Two windows installers are built to support Windows users.:

1. The IDP 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 It runs the standard installer using Property Driven Installation

2. The Jetty installed installer deploys three subsystems

   1. A specific version of Jetty

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

   3. A version of jetty-base for Windows targetted targeted 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 a suitable configured Windows machine) Windows Machine. These pages describe how to build a release of these installers

...

• 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”.

...

This is done using maven, on an appropriate windows machine in . You need to run the idp-msi fileand the idp-bom projects only.

mvn clean install -frf :idp-msi

Sign and deploy the msi file

...

ssh -L 1581:127.0.0.1:1581 -N build.shibboleth.net -f
REM or use Putty
set VERSION=5.1.52
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

...

Installer

There are two parts to releasing the jetty-base Jetty installer:

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

• Building and publishing the msi file

Updating Jetty Base

Preparation

Checkout the source of the relevant jetty version

...

For Jetty 12, we track the project version of jetty-base. The branch we build from is currently named 12-windows

Preparation

• Clone and checkout the correct branch:

  Code Block
  git clone -b 12-windows git@git.shibboleth.net:java-idp-jetty-base cd java-idp-jetty-base

• Merge (not rebase) forward to the latest changes on the 12branch

  Code Block
  git merge 12

• Update the pom to reflect the

...

• jettty and procrun versions

<procrun<version>12.version>10.38.4<0-SNAPSHOT</procrun.version>

<properties>
  <jetty.version>11version>12.0.20<8</jetty.version>

Logback and SLF4J Version

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

   <logback<procrun.version>1.43.14<4</logbackprocrun.version>
    <slf4j.version>2.0.9</slf4j.version>

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

logback.version=1.4.14
slf4j.version=2.0.9

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

git diff jetty-11.0.18 jetty-11.0.20 jetty-server/src/main/config/etc/jetty-ssl-context.xml 
git diff jetty-11.0.18 jetty-11.0.20 jetty-util/src/main/java/org/eclipse/jetty/util/ssl/SslContextFactory.java

The explicit changes are:

--- a/jetty-server/src/main/config/etc/jetty-ssl-context.xml
+++ b/jetty-server/src/main/config/etc/jetty-ssl-context.xml
@@ -5,25 +5,10 @@
     <Arg>
       <New id="sslContextFactory" class="org.eclipse.jetty.util.ssl.SslContextFactory$Server">
         <Set name="Provider" property="jetty.sslContext.provider" />
-        <Set name="KeyStorePath">
-          <Call name="resolvePath" class="org.eclipse.jetty.xml.XmlConfiguration">
-            <Arg><Property name="jetty.base"/></Arg>
-            <Arg><Property name="jetty.sslContext.keyStorePath" deprecated="jetty.sslContext.keyStoreAbsolutePath,jetty.keystore" default="etc/keystore.p12" /></Arg>
-          </Call>
-        </Set>
+        <Set name="KeyStorePath"><Property name="jetty.sslContext.keyStorePath" deprecated="jetty.sslContext.keyStoreAbsolutePath,jetty.keystore" default="etc/keystore.p12" /></Set>
         <Set name="KeyStorePassword"><Property name="jetty.sslContext.keyStorePassword" /></Set>
         <Set name="KeyStoreType" property="jetty.sslContext.keyStoreType" />
         <Set name="KeyStoreProvider" property="jetty.sslContext.keyStoreProvider" />
-        <Set name="KeyManagerPassword"><Property name="jetty.sslContext.keyManagerPassword" /></Set>
-        <Set name="TrustStorePath">
-          <Call name="resolvePath" class="org.eclipse.jetty.xml.XmlConfiguration">
-            <Arg><Property name="jetty.base"/></Arg>
-            <Arg><Property name="jetty.sslContext.trustStorePath" deprecated="jetty.sslContext.trustStoreAbsolutePath,jetty.truststore" /></Arg>
-          </Call>
-        </Set>
-        <Set name="TrustStorePassword" property="jetty.sslContext.trustStorePassword" />
-        <Set name="TrustStoreType" property="jetty.sslContext.trustStoreType" />
-        <Set name="TrustStoreProvider" property="jetty.sslContext.trustStoreProvider" />
         <Set name="EndpointIdentificationAlgorithm" property="jetty.sslContext.endpointIdentificationAlgorithm" />
         <Set name="NeedClientAuth" property="jetty.sslContext.needClientAuth" />
         <Set name="WantClientAuth" property="jetty.sslContext.wantClientAuth" />

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.

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

• Review the 12 version of src\main\resourcs\jetty-base\start.d\idp.ini and make any required changes to src\main\resourcs\jetty-base\start.d.dist\idp-system.ini

• Set revision to zero (f needed)

  Code Block
  <jetty.revision>0</jetty.revision>

Checkout and Test Build

cd %GIT_REPO%
git clone git@git.shibboleth.net:java-idp-jetty-base
cd java-idp-jetty-base
git checkout -b 11-windows origin/11-windows
mvn clean install -Dmaven.repo.local=%MAVEN_REPO%

Smoke Test the installer.

...

• test build and smoke test

• Commit the changes.

Building the Jetty Installer

Set up tag point (and tag if possible)

• Edit pom.xml to remove SNAPSHOT from versions.

• Tag (this may be deferred if running on a GPG deficient build machine)

SET JETTY_TAG=1112.0.188.30-WINDOWS
git add -A
git commit -m "Update files to be tagged for release"
git tag -s -m "Tag %JETTY_TAG%" %JETTY_TAG%

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

<version>11<version>12.0.188.3-SNAPSHOT</version>
<jetty.version>11version>12.0.18<8</jetty.version>
<jetty.revision>3<revision>0</jetty.revision>

• Commit

git add -A
git commit -m "Bump version after release"

Build the release version

git checkout %JETTY_TAG% (or HEAD~1)
mvn -Dmaven.repo.local=%MAVEN_REPO% clean install

Test the released version

Commit the Work

(this assumed that the build was done on a GPG-deficient machine)

• Push the work done above (on the build machine)

• Move msi to GPG machine

• Checkout to the build point and tag

  Code Block
  git pull 12-windows git checkout 12-windows~1 # CHECK at correct point git tag -s -m "Tag %JETTY_TAG%" %JETTY_TAG%

• Clean git reposuitory and move the test msi file into target

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

...

• :

ssh -L 1581:127.0.0.1:1581 -N build.shibboleth.net -f
REM or use Putty
set JETTY_VERSION=1112.0.208
set JETTY_REVISION=0
set VERSION=%JETTY_VERSION%.%JETTY_REVISION%

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=target/shibboleth-jetty-base-x64-%VERSION%.msi -DgroupId=net.shibboleth.idp -DartifactId=idp-jetty-base-windows
SET CL3=-Dversion=%VERSION% -DgeneratePom=false -Dclassifier=msi

Set SIGN_AND_DEPLOY=%CL1% %CL2% %CL3%

%SIGN_AND_DEPLOY%

Push changes to git:

git checkout 1112-windows
git push origin 1112-windows
git push origin %JETTY_TAG%

...

TAG%