From 68cfbc2ced42f244e50ed492eb5dbd306942b7dc Mon Sep 17 00:00:00 2001 From: rcbjBlueMars <9321971+rcbjBlueMars@users.noreply.github.com> Date: Fri, 6 Nov 2026 00:51:45 -0800 Subject: [PATCH] Release 0.1.2 (#35) Tests moved to JUnit 6 and Surefire 3.6.1. No library code or runtime dependency changed. --- CLAUDE.md | 2 +- Dockerfile | 2 +- README.md | 2 +- VERSION | 2 +- demo/pom.xml | 2 +- library/pom.xml | 2 +- pom.xml | 2 +- 7 files changed, 7 insertions(+), 7 deletions(-) diff --git a/CLAUDE.md b/CLAUDE.md index c4d9ac4..10f18b5 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -5,7 +5,7 @@ SPDX-License-Identifier: MIT # wsfed-caep -Java 17 port of the server-side WS-Federation relying party. Group `com.iyasec`, artifact `wsfed-caep`, packages under `com.iyasec.wsfed`. Version 0.1.1. License MIT (`LICENSE`). A pull request merged into `main` publishes the library (`library/` only; the demo never) to Maven Central after the test workflow succeeds on that commit. A direct push does not. `publish.yml` runs `mvn -Prelease -f library/pom.xml deploy` in the Maven container: the `release` profile adds the sources and javadoc jars, a GPG signature on every file, and the Central publishing plugin, which uploads, publishes and waits until the release is live. Maven Central has no trusted publishing, so the job uses four repository secrets: `CENTRAL_TOKEN_USERNAME` and `CENTRAL_TOKEN_PASSWORD` (a Central Portal user token) and `GPG_PRIVATE_KEY` and `GPG_PASSPHRASE` (the release signing key, whose public half is on a public key server). A release on Central is permanent: a version already there is skipped, and the next release is a new version in `VERSION` and the three poms. `-Dcentral.skipPublishing=true` builds and signs everything and uploads nothing. When this tree is published, `develop` and `main` are the same commit. +Java 17 port of the server-side WS-Federation relying party. Group `com.iyasec`, artifact `wsfed-caep`, packages under `com.iyasec.wsfed`. Version 0.1.2. License MIT (`LICENSE`). A pull request merged into `main` publishes the library (`library/` only; the demo never) to Maven Central after the test workflow succeeds on that commit. A direct push does not. `publish.yml` runs `mvn -Prelease -f library/pom.xml deploy` in the Maven container: the `release` profile adds the sources and javadoc jars, a GPG signature on every file, and the Central publishing plugin, which uploads, publishes and waits until the release is live. Maven Central has no trusted publishing, so the job uses four repository secrets: `CENTRAL_TOKEN_USERNAME` and `CENTRAL_TOKEN_PASSWORD` (a Central Portal user token) and `GPG_PRIVATE_KEY` and `GPG_PASSPHRASE` (the release signing key, whose public half is on a public key server). A release on Central is permanent: a version already there is skipped, and the next release is a new version in `VERSION` and the three poms. `-Dcentral.skipPublishing=true` builds and signs everything and uploads nothing. When this tree is published, `develop` and `main` are the same commit. ## Usage diff --git a/Dockerfile b/Dockerfile index 04ae352..04660d4 100644 --- a/Dockerfile +++ b/Dockerfile @@ -31,7 +31,7 @@ WORKDIR /app RUN apt-get update && apt-get install -y --no-install-recommends curl && rm -rf /var/lib/apt/lists/* # The demo's jar under the name the image has always run, and beside it every # runtime dependency, the library jar among them (com.iyasec.wsfed.Cli is there). -COPY --from=build /src/demo/target/wsfed-caep-demo-0.1.1.jar /app/wsfed-caep.jar +COPY --from=build /src/demo/target/wsfed-caep-demo-0.1.2.jar /app/wsfed-caep.jar COPY --from=build /src/demo/target/dependency /app/dependency # The demo, and with it idpCa's file: demo/generated/idp-ca.pem, the iya-sts # listener CA trust chain scripts/configure_iya_sts.py saved. The image trusts diff --git a/README.md b/README.md index f2fb757..2d41a99 100644 --- a/README.md +++ b/README.md @@ -7,7 +7,7 @@ SPDX-License-Identifier: MIT Server-side WS-Federation relying party for Java 17. It accepts SAML 2.0 bearer assertions, reads identity-provider federation metadata, writes relying-party metadata, verifies XML signatures, decrypts encrypted assertions, and remembers assertion ids so a bearer token cannot be replayed. A Shared Signals poll receiver for CAEP and RISC is included. The relying party does not start that receiver. -Group `com.iyasec`, artifact `wsfed-caep`, version 0.1.1. License: MIT. A pull request merged into `main` publishes the library (`library/` only; the demo never) to Maven Central after the test workflow succeeds on that commit. A direct push does not. `publish.yml` runs `mvn -Prelease -f library/pom.xml deploy` in the Maven container: the `release` profile adds the sources and javadoc jars, a GPG signature on every file, and the Central publishing plugin, which uploads, publishes and waits until the release is live. Maven Central has no trusted publishing, so the job uses four repository secrets: `CENTRAL_TOKEN_USERNAME` and `CENTRAL_TOKEN_PASSWORD` (a Central Portal user token) and `GPG_PRIVATE_KEY` and `GPG_PASSPHRASE` (the release signing key, whose public half is on a public key server). A release on Central is permanent: a version already there is skipped, and the next release is a new version in `VERSION` and the three poms. `-Dcentral.skipPublishing=true` builds and signs everything and uploads nothing. `develop` and `main` are the same commit when this tree is published; nothing here creates a remote. +Group `com.iyasec`, artifact `wsfed-caep`, version 0.1.2. License: MIT. A pull request merged into `main` publishes the library (`library/` only; the demo never) to Maven Central after the test workflow succeeds on that commit. A direct push does not. `publish.yml` runs `mvn -Prelease -f library/pom.xml deploy` in the Maven container: the `release` profile adds the sources and javadoc jars, a GPG signature on every file, and the Central publishing plugin, which uploads, publishes and waits until the release is live. Maven Central has no trusted publishing, so the job uses four repository secrets: `CENTRAL_TOKEN_USERNAME` and `CENTRAL_TOKEN_PASSWORD` (a Central Portal user token) and `GPG_PRIVATE_KEY` and `GPG_PASSPHRASE` (the release signing key, whose public half is on a public key server). A release on Central is permanent: a version already there is skipped, and the next release is a new version in `VERSION` and the three poms. `-Dcentral.skipPublishing=true` builds and signs everything and uploads nothing. `develop` and `main` are the same commit when this tree is published; nothing here creates a remote. ## Usage diff --git a/VERSION b/VERSION index 17e51c3..d917d3e 100644 --- a/VERSION +++ b/VERSION @@ -1 +1 @@ -0.1.1 +0.1.2 diff --git a/demo/pom.xml b/demo/pom.xml index 73191a6..fff0a49 100644 --- a/demo/pom.xml +++ b/demo/pom.xml @@ -6,7 +6,7 @@ com.iyasec wsfed-caep-build - 0.1.1 + 0.1.2 wsfed-caep-demo wsfed-caep demo diff --git a/library/pom.xml b/library/pom.xml index b7b0b10..897034d 100644 --- a/library/pom.xml +++ b/library/pom.xml @@ -5,7 +5,7 @@ The demo is the sibling module ../demo, which is never published. --> com.iyasec wsfed-caep - 0.1.1 + 0.1.2 wsfed-caep Server-side WS-Federation relying party that accepts SAML 2.0 assertions, and a CAEP and RISC receiver. https://github.com/rcbj/wsfed-caep-java diff --git a/pom.xml b/pom.xml index e75ec48..2cb9c59 100644 --- a/pom.xml +++ b/pom.xml @@ -6,7 +6,7 @@ is never published. Keep the three versions equal to VERSION. --> com.iyasec wsfed-caep-build - 0.1.1 + 0.1.2 pom wsfed-caep build