Co-bundling Jetty Part II

[Rod Widdowson]

Tom,
Thanks for this...  Some minor comments:

I'd need to think what it means for Windows, but it all makes sense,
although I sense that we need to have some fairly details discussions...

> Meaning, change the
> installation directory from /opt/shibboleth-idp to
> /opt/shibboleth/idp.

In the Windows world that would be \[Program Files|ProgramData!Program Files
(x86)]\Shibboleth\IdP\ (and a similar thing inside the Registry name space).
We might of course go the c:\opt\ approach here as well (although I am not
sure I like this...).  The paradigm is "Manufacturer\Product", and I wonder
whether we should (for Windows only ?) go for "Shibboleth Consortium\IdP"?
Just  a thought.

In the non windows world, what does this mean for the options for rpms and
Linux?  What about Mac or Solaris?  Or is the idea to not go that deep into
the feel of the OS...  Speaking of which, did we bottom out on setUid and
Jetty?
 
> Decouple Jetty and IdPv3 versions by pulling Jetty out of IdPv3 

Makes sense, but again I sense that there are two sides to this
discussion...

> and
> bump it up a level to shibboleth/jetty

I know it's just words, but I’d be happier with some qualification: like
"embedded-jetty" or "captive-jetty", possibly even "java-container".  It
might make it more obvious that this is a container purely for the IdP's
use, not a generic container which other can use.  It just feels to me that
we really need to make the scope and purpose of this visible or we do risk
falling into the support hole. 

> , and tie the Jetty version to
> the Installer version. So remove Jetty as a dependency of the IdP. If
> folks want to use it, great, if not, the IdP does not change.

I see where this is going and it feels nice. I do think that we are going to
need some extensice story boarding around upgrades, repairs/re-installs, and
installation reconfig (user doesn't use jetty, then does, then doesn't) and
so forth.

Rod