parent project should not impose our choice of runtime logging system

This was probably resolved earlier than 11.2, but since I'm pegging the other changes to that version it's simplest.

To address my earlier comment, we do now specify the JCL bridge directly in OpenSAML where needed, as test scope, but the rest of our projects generally use Spring and rely on Spring's bridge.

Resolved by JPAR-169?

We're back to messing with this because of Spring adding its own JCL bridge jar.

While my change today is nominally ok for the IdP, OpenSAML has the HttpClient dependency that means something has to satisfy the JCL dependency to use that feature. I guess that's ordinarily an "optional" dependency? For now I made it test scope there but perhaps changing it to optional is the right move there for security-impl and our other libraries that depend on HttpClient?

Yes, that's an example of the change I meant. I wasn't able to test that far downstream because of the tests failing in the IdP.

We don't want to include jcl-over-slf4j as a general dependency as that would prevent someone deploying with a real commons-logging implementation of logging. We need to only include it "at the last minute" as a runtime dependency.

Not sure it's 100% correct, but the java-idp-testbed is essentially a deployment of the IdP, so I guess it needs runtime deps on at least logback and jcl-over-slf4j

I think jcl-over-slf4j should really be a dependency of the entire stack here because we have libraries that depend on the commons-logging API. From what I can tell, Apache's httpclient and Spring both reference it, and without that in the testbed, the context won't start per the above.