PluginBuildSteps

Owned by Rod Widdowson
Last updated: Aug 19, 2020
2 min read

A Plugin has to be constructed in exactly the right way to allow installation - there are several places where data is unavoidably replcated.

Currently there is no way to automatically ensure that the build will be correct, so this page provides a check list

Pre Build Checks

  • For the parent project
    • Ensure that the parent project versions are correct.  For full release the parent project should be a non-snapshot release) 

    • Check that the dependency versions are non SNAPSHOT.  

      Shibboleth Developers

      Note that for various javadoc reasons the java-parent project defines version properties for java-support, opensaml and spring-extensions, so you will only need to add these if you are depending on a currently unreleased version.  At time of release these  should be removed and the parent pom version matched to the ones used to build the idp (assuming that the parent pom has been moved forward). 
      This ensures that your plugin does not require features not available on the IdP.  If the version properties have to be present (because the parent pom is out of date) then the values must  be equal to or less than the versio in the idp.  But it's easier to start by removing them.

  • In the dist project
    • Ensure that src/main/resources/bootstrap/idp.property  exists and defines a propery pluginId  which must be the same as the value returned by #getPluginId()  in the Dwescription
    • Optionally check that  src/main/resources/bootstrap/keys.txt  contains the public key for corresponding to the private key you are going to sign the package with (see PluginTrust
    • Ensure that any license information is up to date usually in src/main/resources/bootstrap/doc/....
  • In the impl project
    • Ensure that the version numbers returned from the plugin description match the version you are about to build (and as defined in the pom)

    • Ensure that getUpdateURLs()  returns a non-empty list of https URLs pointing to property files that you have write permission for 

      A source control system with a web front end works very well

Build

Build in the usual manner and upload the version to a website.  Maven works well

Post Build Work

  • Update the version number in the Description to match the pom
  • Update the property file to reflect the new release.
    • Change the supportLevel of the old version appropriately.  Levels are defined in net.shibboleth.idp.plugin.PluginSupport.SupportLevel  (in idp module idp=admin-api} and currently consist of
      • Current
      • OutOfDate
      • Unsupported
      • Secadv
      • Withdrawn
    • Add downloadURL and baseName information about the new release.
    • The idpVersionMin for the new release  will usually be the version of the IdP that that version of the plugin was built against.

  • An example file is available here 

    net.shibboleth.idp.plugin.nashorn.versions=0.1.0 0.1.1
#
# NASHORN
# 0.1.0
#
net.shibboleth.idp.plugin.nashorn.idpVersionMax.0.1.0=5.0.0
net.shibboleth.idp.plugin.nashorn.idpVersionMin.0.1.0=4.1.0
net.shibboleth.idp.plugin.nashorn.supportLevel.0.1.0 = OutOfDate
net.shibboleth.idp.plugin.nashorn.downloadURL.0.1.0 = https://build.shibboleth.net/nexus/service/local/repositories/releases/content/net/shibboleth/idp/plugin/scripting/idp-plugin-nashorn-dist/0.1.0
net.shibboleth.idp.plugin.nashorn.baseName.0.1.0 = idp-plugin-nashorn-dist-0.1.0
#
# 0.1.1
#
net.shibboleth.idp.plugin.nashorn.idpVersionMax.0.1.1=5.0.0
net.shibboleth.idp.plugin.nashorn.idpVersionMin.0.1.1=4.1.0
net.shibboleth.idp.plugin.nashorn.supportLevel.0.1.1 = Current