Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

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

Table of Contents
stylenone

Prerequisites (one-off)

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

...

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

Code Block
mvn clean install -frf :idp-msi
Note

Make sure that the bom project runs - this will run the “m2 enforcer”.

Sign and deploy the msi file

...

Code Block
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%

If you are deploying a version with a non zero version (e.g. 5.1.2.1) you will need to rename the msi file by hand.

Building a Release of the Jetty Installer

There are two parts to releasing the Jetty installer:

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

  • Building and publishing the

...

Note

in progress

...

  • msi file

Updating Jetty Base

The following is for Jetty 12.x

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

Code Block
<version>12.0.8.0-SNAPSHOT</version>

<properties>
  <jetty.version>12.0.8</jetty.version>
  <procrun.version>1.3.4</procrun.version>
...
  • 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>
  • 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)

Code Block
SET JETTY_TAG=12.0.8.0-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

Code Block
<version>12.0.8.3-SNAPSHOT</version>
<jetty.version>12.0.8</jetty.version>
<jetty.revision>0</jetty.revision>
  • Commit

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

Build the release version

Code Block
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:

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

Code Block
git checkout 12-windows
git push origin 12-windows
git push origin %JETTY_TAG% 

There are two batch files src\main\bin\setrepos.bat and src\main\bin\setvariables.bat which set things up.