Introduction

...

The plugin ID and the initial keystore are included as text (so no suspect jar need be on the classpath) in a directory with is part of the package (but not installed) called "bootstrap".  This contains two files

• id.property a file with a single property in it pluginid 
• keys.txt  the signing keys.  This is optional.  See PluginTrust

...

Behind all this is a feeling that there is a "turtles all the way down" solution by which the IdP also exports most of the Service Interface and this can therefore be used to drive update detection and testing and even "download and update" the IdP.  

IdP Updates Insert

IdP update needs to be modfiied to preserve the dist\edit-webapp-pluginID  folders.

...

• Bouncy castle (for GPG signature checking).
  • This is already a dependency, so we assume that we are covered
• Commons-compress (needed to unpick tgz files) 
  • This is Apache licensed
  • But its dependencies are not and work is need to fulfill their requirements. (one 2-Clause BSD , one MIT)
    • It looks as thought the stated dependencies are not real,  They do not live in the POM and they are not in our repository.
• The is the perpetual where to put the classes question.
  • This is all being developed in the idp-installer project
  • But if we want to report about plugin status in  an admin page or jsp or some sy

Further documentation

• Plugin Archetype
• PluginPOMGuidance
• PluginTestbedGuidance
• PluginTrust
• PluginBuildSteps