Merging the shared Java code repositories

Status: latest merge to java-shib-shared was on 2022-06-20.

This page has some notes and status information related to the following Jira issue:

https://shibboleth.atlassian.net/browse/JPAR-210

There are two repositories in the @converting category associated with this work:

  • make-shib-shared holds the scripts to build the new repository. It has a README.md describing how that’s done.

  • java-shib-shared is the (straw man) version of the new repository.

These repositories are read-write for iay, read-only for other committers and not presented via gitweb. They can be updated if we change assumptions or update the source repositories (the latter is already the case), but there's no way to preserve any changes pushed to them if we need to re-run the build process. Once they become read-write, there's really no way back.

The straw man is built under the following assumptions, all of which may change before we declare victory:

  • At this stage, we’re not planning to refactor any of the code in either source repository. We may do that later to disaggregate the current java-supportartifact.

  • This will turn into a multi-module project, with a pom.xml in the root directory of this new repository, in the way we’ve done with the MDA and some of the plugin repositories, rather than the side-by-side scheme we used in the IdP and OpenSAML. This hasn’t been done yet.

  • We don’t intend to use this new merged repository to rebuild historic versions of the artifacts, or to do any necessary maintenance on previous versions (however, there’s no reason to make it impossible, either). There’s no current intention to remove the old repositories, and that work can be done there. This means that all non-dev/ branch names carried over from the old repositories have been stripped from the new repository.

  • Initially, we’re leaving the file names and Maven coordinates for the two artifacts generated as they are. Longer term, we want to rename those because their current names aren’t well chosen. I’m assuming that we want to change from java-support to shib-support and from spring-extensions to shib-spring.

  • To align with that, the histories for the two source repositories are moved into sub-directories with those names (shib-support and shib-spring).

  • The GPG/PGP signatures have been stripped from all signed tags. It’s not possible to perform any of the surgery required and preserve these as functional signatures, and removing them seems better than leaving them intact but non-functional.

The Git history for the java-shib-shared repository looks like this:

  • There’s an empty root commit dated 2010-01-01T00:00Z. This timestamp predates the earliest commit in each of the source repository.

  • Two branches come out of the root commit, one for each source repository.

  • The main branch of the new repository is a merge between the two histories of the source repositories.

  • Tags from the source repositories are present with support- or spring- prefixes as appropriate.

  • All dev/ branches from the source repositories have been rebased to the new main. The script handles new ones programmatically so there appears to be no need to resolve dev/ branches before the merge.

This all means that for example git log shib-support/pom.xmldoes what you’d want.

New output from git branch:

1 2 3 4 5 dev/spring-JSPS-1 dev/spring-JSPT-98 dev/support-JSPT-111 dev/support-JSPT-98 * main

New output from git tag:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 spring-5.4.0 spring-5.4.1 spring-5.4.2 spring-6.0.0 spring-6.0.0-beta1 spring-6.0.0-beta2 spring-6.1.0 spring-6.1.1 spring-6.1.2 spring-6.1.3 spring-6.2.0 support-1.0.0 support-7.4.0 support-7.4.1 support-7.4.2 support-7.5.0 support-7.5.1 support-7.5.2 support-8.0.0 support-8.0.0-beta1 support-8.0.0-beta2 support-8.1.0 support-8.2.0 support-8.2.1 support-8.3.0 support-8.3.1