Merge pull request #2904 from hongwei1/chore/remove-retired-lift-standards

refactor: remove retired API standards and superseded Lift stubs

Author: simonredfern

.github/jmx_exporter.config

@@ -200,6 +200,18 @@ jobs:
             # discovery excludes this same prefix so no test runs in both shards.
             test_filter: >-
               code.api.v4_0_0.Dynamic
+          - shard: 10
+            name: "PropGatedPublicEndpoint (read_*_requires_role=true)"
+            # JsonSchemaValidationPublicPropTrueTest / AuthenticationTypeValidationPublicPropTrueTest
+            # need read_json_schema_validation_requires_role /
+            # read_authentication_type_validation_requires_role forced true, which is baked into
+            # Http4s400's ResourceDoc error list at object-init time -- a value only one JVM can
+            # observe. Every other shard boots with these props unset (false, the default) and
+            # the pom.xml default tagsToExclude skips this tag there. This shard is the only place
+            # the true branch is exercised; see the "Run tests" step's shard-10 special case below.
+            test_filter: >-
+              code.api.v4_0_0.JsonSchemaValidationPublicPropTrueTest
+              code.api.v4_0_0.AuthenticationTypeValidationPublicPropTrueTest
 
     services:
       redis:
@@ -373,6 +385,18 @@ jobs:
             FILTER="${FILTER}${EXTRAS}"
           fi
 
+          # Shard 10: PropGatedPublicEndpoint tests need read_json_schema_validation_requires_role /
+          # read_authentication_type_validation_requires_role forced true and the
+          # PropGatedPublicEndpoint tag included (pom.xml's default tagsToExclude skips it
+          # everywhere else). These two OBP_* env vars and the tag override apply only to this
+          # shard's mvn invocation below.
+          EXTRA_MVN_ARGS=""
+          if [ "${{ matrix.shard }}" = "10" ]; then
+            export OBP_READ_JSON_SCHEMA_VALIDATION_REQUIRES_ROLE="true"
+            export OBP_READ_AUTHENTICATION_TYPE_VALIDATION_REQUIRES_ROLE="true"
+            EXTRA_MVN_ARGS="-DtagsToInclude=PropGatedPublicEndpoint -Dtest.tagsToExclude="
+          fi
+
           # `mvn process-resources scalatest:test` — run process-resources (copies the
           # dynamically-generated props from src/main/resources onto the classpath at
           # target/classes/props) then the scalatest:test goal. This SKIPS the
@@ -391,7 +415,7 @@ jobs:
           set +e
           MAVEN_OPTS="-Xmx3G -Xss2m -XX:MaxMetaspaceSize=1G" \
             timeout 1500 mvn process-resources scalatest:test -pl obp-commons,obp-api -DfailIfNoTests=false \
-              -DwildcardSuites="$FILTER" \
+              -DwildcardSuites="$FILTER" $EXTRA_MVN_ARGS \
             > maven-build-shard${{ matrix.shard }}.log 2>&1
           rc=$?
           set -e
@@ -438,6 +462,20 @@ jobs:
             echo "No failing tests detected in shard ${{ matrix.shard }}."
           fi
 
+          # "No failures" is not "it ran". A shard whose filter matches nothing, or
+          # whose tag override stops taking effect, executes zero tests, matches no
+          # failure pattern and reports green -- the same false green the
+          # process-resources note above guards against, from a different direction.
+          # Shard 10 is the exposed one: its suites only run while
+          # -DtagsToInclude=PropGatedPublicEndpoint -Dtest.tagsToExclude= holds.
+          RAN=$(grep -oE "Tests: succeeded [0-9]+" maven-build-shard${{ matrix.shard }}.log \
+                | awk '{s+=$3} END {print s+0}')
+          echo "Shard ${{ matrix.shard }} executed ${RAN} tests."
+          if [ "${RAN}" -eq 0 ]; then
+            echo "Shard ${{ matrix.shard }} ran no tests at all — treating as failure."
+            exit 1
+          fi
+
       - name: Upload Maven build log — shard ${{ matrix.shard }}
         if: always()
         uses: actions/upload-artifact@v4

.github/logback.xml

@@ -194,6 +194,18 @@ jobs:
             # discovery excludes this same prefix so no test runs in both shards.
             test_filter: >-
               code.api.v4_0_0.Dynamic
+          - shard: 10
+            name: "PropGatedPublicEndpoint (read_*_requires_role=true)"
+            # JsonSchemaValidationPublicPropTrueTest / AuthenticationTypeValidationPublicPropTrueTest
+            # need read_json_schema_validation_requires_role /
+            # read_authentication_type_validation_requires_role forced true, which is baked into
+            # Http4s400's ResourceDoc error list at object-init time -- a value only one JVM can
+            # observe. Every other shard boots with these props unset (false, the default) and
+            # the pom.xml default tagsToExclude skips this tag there. This shard is the only place
+            # the true branch is exercised; see the "Run tests" step's shard-10 special case below.
+            test_filter: >-
+              code.api.v4_0_0.JsonSchemaValidationPublicPropTrueTest
+              code.api.v4_0_0.AuthenticationTypeValidationPublicPropTrueTest
 
     services:
       redis:
@@ -377,6 +389,18 @@ jobs:
             FILTER="${FILTER}${EXTRAS}"
           fi
 
+          # Shard 10: PropGatedPublicEndpoint tests need read_json_schema_validation_requires_role /
+          # read_authentication_type_validation_requires_role forced true and the
+          # PropGatedPublicEndpoint tag included (pom.xml's default tagsToExclude skips it
+          # everywhere else). These two OBP_* env vars and the tag override apply only to this
+          # shard's mvn invocation below.
+          EXTRA_MVN_ARGS=""
+          if [ "${{ matrix.shard }}" = "10" ]; then
+            export OBP_READ_JSON_SCHEMA_VALIDATION_REQUIRES_ROLE="true"
+            export OBP_READ_AUTHENTICATION_TYPE_VALIDATION_REQUIRES_ROLE="true"
+            EXTRA_MVN_ARGS="-DtagsToInclude=PropGatedPublicEndpoint -Dtest.tagsToExclude="
+          fi
+
           # `mvn process-resources scalatest:test` — run process-resources (copies the
           # dynamically-generated props from src/main/resources onto the classpath at
           # target/classes/props) then the scalatest:test goal. This SKIPS the
@@ -395,7 +419,7 @@ jobs:
           set +e
           MAVEN_OPTS="-Xmx3G -Xss2m -XX:MaxMetaspaceSize=1G" \
             timeout 1500 mvn process-resources scalatest:test -pl obp-commons,obp-api -DfailIfNoTests=false \
-              -DwildcardSuites="$FILTER" \
+              -DwildcardSuites="$FILTER" $EXTRA_MVN_ARGS \
             > maven-build-shard${{ matrix.shard }}.log 2>&1
           rc=$?
           set -e
@@ -442,6 +466,20 @@ jobs:
             echo "No failing tests detected in shard ${{ matrix.shard }}."
           fi
 
+          # "No failures" is not "it ran". A shard whose filter matches nothing, or
+          # whose tag override stops taking effect, executes zero tests, matches no
+          # failure pattern and reports green -- the same false green the
+          # process-resources note above guards against, from a different direction.
+          # Shard 10 is the exposed one: its suites only run while
+          # -DtagsToInclude=PropGatedPublicEndpoint -Dtest.tagsToExclude= holds.
+          RAN=$(grep -oE "Tests: succeeded [0-9]+" maven-build-shard${{ matrix.shard }}.log \
+                | awk '{s+=$3} END {print s+0}')
+          echo "Shard ${{ matrix.shard }} executed ${RAN} tests."
+          if [ "${RAN}" -eq 0 ]; then
+            echo "Shard ${{ matrix.shard }} ran no tests at all — treating as failure."
+            exit 1
+          fi
+
       - name: Upload Maven build log — shard ${{ matrix.shard }}
         if: always()
         uses: actions/upload-artifact@v4

.github/workflows/auto_update_base_image.yml_disabled

@@ -6,7 +6,7 @@
 - Commit messages, code comments, and PR titles/descriptions: no AI/tool names (Claude, GPT, Copilot, etc.), no AI-typical filler phrasing ("Certainly!", "I'll help you with..."), no emoji, no "AI-generated"/"LLM" labels. Use plain Conventional Commits style (`fix:`, `feat:`, `refactor:`, ...) and set commit author/committer to the actual person directing the work.
 - **Goal is full http4s migration** — eliminate Lift Web and all deprecated libraries entirely. Treat Lift code as temporary scaffolding to be removed, not maintained. When fixing bugs or adding features, always prefer the http4s path.
 - **Versioning is tech-agnostic** — API version numbers reflect API signature changes (new/changed fields, new behaviour), never the underlying framework. A framework migration (Lift → http4s) happens in-place at the existing version; it does not justify a version bump.
-- **`APIMethodsXYZ.scala` (Lift) files are the source of truth for migration.** The commented-out Lift ResourceDocs and endpoints inside each `APIMethodsXYZ.scala` are the canonical reference for what the http4s version should match: URL templates, verb casing, summaries, descriptions, example bodies, error lists, tags. **Do NOT edit these files to make the parity audit pass.** The audit compares http4s against the Lift source-of-truth — when it flags a diff, the fix is to either (a) update http4s to match Lift, or (b) document the difference at the http4s site as a known intentional drift (e.g. a placeholder rename for `ResourceDocMatcher` middleware, or an upstream-driven case-class shape change). Rewriting the Lift comments to match http4s runs the comparison backwards and destroys the historical record. See `scripts/check_lift_http4s_resource_doc_parity.py` for the audit, and `scripts/rehydrate_resource_docs.py` / `scripts/restore_resource_doc_bodies.py` for the canonical Lift → http4s restoration tools.
+- **`scripts/resource_doc_baseline/lift_resource_docs_vX_Y_Z.json` is the source of truth for migration.** The 12 `APIMethodsXYZ.scala` files that used to hold this as commented-out Lift `ResourceDoc` text have been deleted (they had shrunk to thin runtime shims plus ~60,000 lines of dead comments — see git history for their last content, or `scripts/resource_doc_baseline/README.md` for the full story). The JSON baseline is the canonical reference for what the http4s version should match: URL templates, verb casing, summaries, descriptions, example bodies, error lists, tags — each field stored as the literal, unevaluated Scala source snippet it always was. **Do NOT hand-edit this JSON to make the parity audit pass**, for the same reason you never edited the old Lift comments for that purpose: it's the historical record the audit compares http4s against. When the audit flags a diff, the fix is to either (a) update http4s to match the baseline, or (b) if it's a reviewed, intentional difference, add a digest-bound entry to `scripts/resource_doc_baseline/parity_allowlist.json` (see that directory's README for the exact workflow — use `allowlist_helper.py`, don't hand-compute digests). See `scripts/check_lift_http4s_resource_doc_parity.py` for the audit (now reads the JSON baseline on the Lift side, live `.scala` on the http4s side), and `scripts/rehydrate_resource_docs.py` / `scripts/restore_resource_doc_bodies.py` for the canonical baseline → http4s restoration tools (also JSON-sourced now).
 
 ## Architecture (Onboarding)
 
@@ -115,7 +115,7 @@ But: if the inline check uses the **same** role as the doc (e.g. v5 `createAccou
 
 **`StoredProcedureUtils` in tests**: `StoredProcedureUtils` has a constructor block that requires `stored_procedure_connector.*` props. In the test environment these aren't set, so the first access to the object (inside `Future { StoredProcedureUtils.getHealth() }`) throws and returns 500. Only test the 401/403 scenarios for `getStoredProcedureConnectorHealth` — skip the 200 scenario.
 
-**`resource-docs` version dispatch**: `GET /obp/v7.0.0/resource-docs/API_VERSION/obp` accepts any valid API version string. Delegates to `ResourceDocs140.ImplementationsResourceDocs.getResourceDocsList(requestedApiVersion)` which dispatches per version (v7.0.0 → `Http4s700.resourceDocs`, v6.0.0 → `OBPAPI6_0_0.allResourceDocs`, etc.). An invalid/unknown version string returns 400.
+**`resource-docs` version dispatch**: `GET /obp/v7.0.0/resource-docs/API_VERSION/obp` accepts any valid API version string. Delegates to `ResourceDocs140.ImplementationsResourceDocs.getResourceDocsList(requestedApiVersion)` which dispatches per version (v7.0.0 → `Http4s700.resourceDocs`, v6.0.0 → `Http4sResourceDocAggregation.v600`, etc.). An invalid/unknown version string returns 400.
 
 **System owner view** (`"owner"`) has `CAN_GET_COUNTERPARTY` and is granted to `resourceUser1` on all test accounts — safe to use as VIEW_ID in tests.
 
@@ -274,7 +274,7 @@ Perf note: integration tests are DB/HTTP-bound (~0.4 s/test) on both frameworks;
 
 ### Shard assignment
 
-Shards are defined per-matrix-entry in `.github/workflows/build_pull_request.yml` and `.github/workflows/build_container.yml` (both files carry an identical 9-shard matrix — update both when reshaping). Shard 8 runs a **catch-all**: any `.scala` test file whose package is not covered by shards 1–7 and 9 is appended automatically at runtime — new packages are never silently skipped. Extras are printed in the step log under `"Catch-all extras added to shard 8"`. Shard 1 (`code.api.v4_0_0` non-Dynamic) is itself discovered at runtime rather than hand-listed — see the "Run tests" step's `matrix.shard = 1` branch — specifically so a newly added class in that package can never fall through both shard 1 and the catch-all.
+Shards are defined per-matrix-entry in `.github/workflows/build_pull_request.yml` and `.github/workflows/build_container.yml` (both files carry an identical 10-shard matrix — update both when reshaping). Shard 8 runs a **catch-all**: any `.scala` test file whose package is not covered by shards 1–7, 9, and 10 is appended automatically at runtime — new packages are never silently skipped. Extras are printed in the step log under `"Catch-all extras added to shard 8"`. Shard 1 (`code.api.v4_0_0` non-Dynamic) is itself discovered at runtime rather than hand-listed — see the "Run tests" step's `matrix.shard = 1` branch — specifically so a newly added class in that package can never fall through both shard 1 and the catch-all.
 
 | Package prefix | Shard |
 |---|---|
@@ -288,6 +288,9 @@ Shards are defined per-matrix-entry in `.github/workflows/build_pull_request.yml
 | `code.connector`, `code.util`, `code.api.Authentication*`, `code.api.dauthTest`, `code.api.DirectLoginTest`, `code.api.gateWayloginTest`, `code.api.OBPRestHelperTest`, `code.entitlement`, `code.bankaccountcreation`, `code.bankconnectors`, `code.container`, `code.management`, `code.metrics`, `code.concurrency` | 8 |
 | anything else | **8** (catch-all) |
 | `code.api.v4_0_0.Dynamic*` | 9 |
+| `code.api.v4_0_0.JsonSchemaValidationPublicPropTrueTest`, `code.api.v4_0_0.AuthenticationTypeValidationPublicPropTrueTest` (tagged `PropGatedPublicEndpoint`) | 10 |
+
+Shard 10 is a special case: it's the only shard that overrides pom.xml's default `tagsToExclude` (which otherwise skips `PropGatedPublicEndpoint` everywhere) and sets `OBP_READ_JSON_SCHEMA_VALIDATION_REQUIRES_ROLE`/`OBP_READ_AUTHENTICATION_TYPE_VALIDATION_REQUIRES_ROLE=true`, because those two props are baked into `Http4s400`'s `ResourceDoc` error lists at object-init time — a single JVM can only ever observe one value of each, so the `true` branch needs its own shard while every other shard (which boots with the props unset, i.e. `false`) exercises the default branch. `run_tests_parallel.sh` (local runner) mirrors this with a dedicated sequential step after its 4 main shards — see that script's own comment near `PropGatedPublicEndpoint`.
 
 To explicitly move a package to a different shard, add it to that shard's `test_filter` block — it will be excluded from the catch-all automatically. `run_tests_parallel.sh` (local runner) uses a coarser 4-shard layout that folds all 9 CI shards' coverage into 4 wildcardSuites groups — see its own header comment for the mapping.
 

.github/workflows/build_container.yml

@@ -172,39 +172,6 @@ class FundsAvailableTest extends V310ServerSetup {
 }
 ```
 
-## Code Generation
-
-We support to generate the OBP-API code from the following three types of json. You can choose one of them as your own requirements.
-
-    1 Choose one of the following types: type1 or type2 or type3
-    2 Modify the json file your selected, for now, we only support these three types: String, Double, Int. other types may throw the exceptions
-    3 Run the Main method according to your json file
-    4 Run/Restart OBP-API project.
-    5 Run API_Exploer project to test your new APIs. (click the Tag `APIBuilder B1)
-
-Here are the three types:
-
-Type1: If you use `modelSource.json`, please run `APIBuilderModel.scala` main method
-
-```
-/OBP-API/obp-api/src/main/resources/apiBuilder/APIModelSource.json
-/OBP-API/obp-api/src/main/scala/code/api/APIBuilder/APIBuilderModel.scala
-```
-
-Type2: If you use `apisResource.json`, please run `APIBuilder.scala` main method
-
-```
-/OBP-API/obp-api/src/main/resources/apiBuilder/apisResource.json
-OBP-API/src/main/scala/code/api/APIBuilder/APIBuilder.scala
-```
-
-Type3: If you use `swaggerResource.json`, please run `APIBuilderSwagger.scala` main method
-
-```
-/OBP-API/obp-api/src/main/resources/apiBuilder/swaggerResource.json
-OBP-API/src/main/scala/code/api/APIBuilder/APIBuilderSwagger.scala
-```
-
 ## Issues
 
 If would like to report an issue or suggest any kind of improvement please use Github Issues.