Status: latest merge to java-shib-shared was on 2022-06-15.
This page has some personal notes and status information related to the following Jira issue:
JPAR-210 - Getting issue details... STATUS
There are two repositories in the @converting category associated with this work:
make-shib-sharedholds the scripts to build the new repository. It has aREADME.mddescribing how that’s done.java-shib-sharedis 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.At this stage, we’re not trying to make this into a multi-module project. We do want to do that longer term, with the assumption being that we’d put the
pom.xmlinto 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.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 should mean that we can strip all branch names carried over from the old repositories, and I think there’s a good argument that we should do so.
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-supporttoshib-supportand fromspring-extensionstoshib-spring.To align with that, the histories for the two source repositories are moved into sub-directories with those names (
shib-supportandshib-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. Branches and tags from the source repositories are all prefixed with
support-orspring-as appropriate. For example themainbranch fromjava-supportis calledsupport-mainin the new repository.The
mainbranch of the new repository is a merge between thesupport-mainandspring-mainbranches.All
dev/branches from the source repositories have been rebased to the newmain. The script handles new ones programmatically so there appears to be no need to resolvedev/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:
dev/spring-JSPS-1 dev/spring-JSPT-98 dev/support-JSPT-111 dev/support-JSPT-98 * main spring-main spring-maint-5 spring-maint-6 support-main support-maint-7 support-maint-8
New output from git tag:
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