Recast IDP Installer to use the CLI infrastructure
Description
Environment
duplicates
Confluence content
Activity
Recasting it down to the shib-cli parents worked fine.
I think we’re stretching things a little to try and reuse the IdP’s CLI classes because they certainly depend on a real IdP. Per my other comment, does using the lower layer untangle this at all?
I think the way I want to fix this problem (see previous comment) is to change the IdPPropertiesApplicationContextInitializer to not try to traverse looking for *.properties files if idp.home is on the classpath.
I have prototyped this (retaining the API level compatibility of that class) and it works file.
My only concern is that this approach makes running with idp.home as the classpath a production thing. Admittedly it is only within the very constrained world of the IdP installer, and the one thing we want this for (https://shibboleth.atlassian.net/browse/IDP-1961) will probably not be running like this.
@Scott Cantor I’d be interested in your take
Ugh. In order to make this work we need to make install.sh/bat run with a classpath of classpath:/net/shibboleth/idp/module If we do this then the traversal of directories fails. This is because our idp.properties say “do this”. We could clone idp.properties into the jar for the installer but that gives me the heeby-jeebies because of the certainty that it would diverge.
build (war creation - inside an installation) is now done.
install (or update from within a distribution still to be done)
To keep the impedance low, the V4 installer was built as an ant task (so install.sh calls ant.sh which runs ant on build.xml)
Since V4 was released we have introduced a complete infrastructure for running command lines from the CLI including support for spring and properties both of which the IdP installer (currently) uses.
We should collapse away the ant task bit and use a CLI directly.
Note that this is a different question from whether we want to stop using ANT. There are many operations that would be a pain to implement outside ant (for instance setting and clearing the RO bit on windows or building war files) so I don't see it going away unless there is a good reason (or better alternative) but to be calling the installer from an ant script feels like overkill long term. It was a handy stepping stone but that time has passed.