Test 3.1 branch via Jenkins

Triggers :

SCM -> java-identity-provider-3.1 -> java-idp-integration-tests-3.1 -> java-identity-provider-nightly-3.1 and java-identity-provider-nightly-central-disabled-3.1

Upshot is, a change to the 3.1 branch results in tests being run, which if they pass, deploys a new snapshot.

"Nightly" isn't the best name, therefor, but it corresponds to the V3 jobs.

Integration tests pass against IdP 3.1 using r59 (of the integration tests).

Changed the Repository URL of java-idp-integration-tests-3.1 to https://svn.shibboleth.net/java-idp-integration-tests/trunk@59

Oh. So, the integration tests which test local storage fail against the 3.1 branch, obviously because those flows don't exist (in that branch). I've done a horrible job of versioning java-idp-testbed and java-idp-integration-tests. The question I have is, should we treat those two test projects as "real" projects and version them and add them to JIRA, etc. ? If not, I think Jenkins should checkout a revision of the integration tests that does not include the local storage tests, that's probably the least work, but I don't know if that scales well for the future.

• Created a "V3.1" view in the Jenkins dashboard.

• Copied java-identity-provider to java-identity-provider-3.1 and adjusted the Repository URL in the job configuration.

• Copied java-identity-provider-nightly to java-identity-provider-nightly-3.1 and adjusted the Repository URL in the job configuration. Removed building java-idp-testbed from "Build other projects" Post-build Action.

• Copied java-identity-provider-nightly-central-disabled to java-identity-provider-nightly-central-disabled-3.1 and adjusted the Repository URL in the job configuration.

Need to decide how to trigger deploying the 3.1 SNAPSHOT, maybe add something to the trigger-nightly-v3 job, we shouldn't run the trunk and branch integration tests running at the same time without using separate ports.