Alignment / Usage of `stacks-java-module-parent` across Ensono Stacks

[RichardSlater]

Summary

This issue tracks aligning Ensono stacks-java-* repositories with the canonical parent POM maintained in this repository (stacks-java-module-parent). The goal is to ensure a consistent parent POM across active Java modules, using version v3.0.66 (latest as of 2025-09-15), and to skip archived/sample repositories.

Why: a single maintained parent POM centralizes dependency management, plugin configuration, security patches and CI conventions (OWASP, fmt, checkstyle, spotbugs, jacoco, etc.). Some repositories still reference the older groupId com.amido.stacks.modules or use other parents (for example spring-boot-starter-parent).

Target parent coordinates to apply in child POMs:

<parent>
  <groupId>com.ensono.stacks.modules</groupId>
  <artifactId>stacks-modules-parent</artifactId>
  <version>3.0.94</version>
</parent>

Current state (summary)

• Repos scanned: all stacks-java-* in the Ensono org (18 matches).
• Many active Java modules already declare <parent> with artifactId stacks-modules-parent but several point at the older groupId com.amido.stacks.modules and different versions.
• Some sample and archived repos do not contain a usable pom.xml at the root or are archived and should be skipped.
• A few projects (demo/sample or Micronaut demos) intentionally do not consume the parent and should be reviewed before changing.

Scope & exclusions

• Scope: active repositories whose names start with stacks-java- containing Java modules intended to be part of the Stacks family. We'll modify module POMs that are under active maintenance.
• Exclusions: archived repositories, sample/demo-only repos, and projects whose intent is to remain independent (e.g., Micronaut demo) unless a maintainer requests adoption.

Acceptance criteria

1. Active Java modules that are part of Stacks use the parent POM with groupId com.ensono.stacks.modules, artifactId stacks-modules-parent, version 3.0.94.
2. CI builds in a feature branch pass (at minimum mvn -DskipTests verify or the repo's existing CI) for each updated repo.
3. PRs are opened for each repository with clear description and QA instructions.

Action plan (checklist)

• Prepare a small automated script to: clone targeted repos, find module POM(s) (root or java/pom.xml), update <parent> to v3.0.66 or add it when missing (careful), and run a smoke build.

  • Implementation notes:
    • Detect the child pom path (try pom.xml, java/pom.xml).
    • If existing <parent> has groupId com.amido.stacks.modules, update the groupId to com.ensono.stacks.modules and the version to 3.0.94.
    • If no <parent> and the project is an active Stacks module, propose adding the parent block (include relativePath if necessary).
    • Skip repos where the code is archived or flagged as samples.

• Run the script locally for a small pilot set (2-3 active repos). Validate builds and address any plugin or property regressions.

• Create branches and open PRs per-repo. Each PR should include:

  • Purpose and impact statement
  • CI run status (smoke build logs)
  • Testing notes (how to reproduce locally)
  • Rollback/Backout instructions (how to revert the parent change)

• Request maintainers' review on each PR. Address any feedback.

• Merge PRs after approval and passing CI.

• Update central documentation (this README and the amido.github.io or equivalent docs) to note that v3.0.94 is the recommended parent.

• Follow-up: schedule a periodic check (quarterly) to ensure modules remain on supported parent version.

References

• This repository (parent POM) — reference parent POM and its owasp-dependency-check profile and other shared build configuration: pom.xml in this repo.
• Org code search results for stacks-modules-parent (examples pulled from multiple repos): many java/pom.xml files reference the artifactId stacks-modules-parent with groupId com.amido.stacks.modules or com.ensono.stacks.modules.
• Rationale: consistent dependency management and plugin versions (fmt, spotbugs, checkstyle, OWASP dependency-check) reduces drift and security risk.

Security impact

• Standardizing on the parent POM centralizes the versions of security-sensitive plugins and libraries (for example, Gson, Netty, OWASP plugin versions). This helps apply timely security updates across modules.

Notes and caveats

• Some repositories intentionally use spring-boot-starter-parent or other special parents; changing the parent may require merging plugin config (for spring-boot-maven-plugin settings) into the stacks parent or a custom child configuration. Treat these on a case-by-case basis.
• For multi-module repos, be careful to update module POMs not aggregator-only POMs unless intended.

If you'd like, I can prepare the pilot script and open PRs for a small batch of repos (2–3) so you can review the pattern before wider rollout. Please confirm:

• The target version to apply: 3.0.94 (confirmed)
• Whether to skip archived/sample repos: yes, skip them
• If you want me to open PRs or just produce patch files for manual review: choose one

This document tracks the stacks-java-* repositories discovered in the Ensono organization during the repo inventory run. It records where a pom.xml was found (root or java/pom.xml), whether the child POM references stacks-modules-parent, and notes about groupId (com.ensono vs com.amido), archived/sample status, or missing files.

Notes:

• Target parent: com.ensono.stacks.modules:stacks-modules-parent:3.0.94
• "References parent" means the child POM contains a <parent> block with artifactId stacks-modules-parent.
• Where possible links point to the file path used during the inspection (downloaded from GitHub during the session).

Inventory (observed repos)

1. stacks-java-module-parent

   • Path inspected: pom.xml (this repo)
   • Notes: canonical parent POM (source of truth). Contains OWASP dependency-check profile.

2. stacks-java-core-commons

   • Path inspected: java/pom.xml
   • References parent: yes
   • groupId observed: com.ensono.stacks.modules (already using the canonical groupId)

3. stacks-java-core-api

   • Path inspected: java/pom.xml
   • References parent: yes
   • groupId observed: com.amido.stacks.modules (older groupId)

4. stacks-java-azure-cosmos

   • Path inspected: java/pom.xml
   • References parent: yes
   • groupId observed: com.amido.stacks.modules

5. stacks-java-aws-dynamodb

   • Path inspected: java/pom.xml
   • References parent: yes
   • groupId observed: com.amido.stacks.modules

6. stacks-java-core-messaging

   • Path inspected: java/pom.xml
   • References parent: yes
   • groupId observed: com.amido.stacks.modules

7. stacks-java-core-cqrs

   • Path inspected: java/pom.xml
   • References parent: yes
   • groupId observed: com.amido.stacks.modules

8. stacks-java-azure-servicebus

   • Path inspected: java/pom.xml
   • References parent: yes
   • groupId observed: com.amido.stacks.modules

9. stacks-java-aws-sqs

   • Path inspected: attempted java/pom.xml (404)
   • Status: missing pom.xml at inspected path or repo layout differs; may be archived or not a Java module.

10. stacks-java-cqrs

    • Path inspected: java/pom.xml (if present)
    • References parent: yes (in many modules)
    • groupId observed: mixed (some modules use com.amido.stacks.modules)

11. stacks-java-cqrs-events

    • Path inspected: java/pom.xml
    • References parent: yes
    • groupId observed: com.amido.stacks.modules

12. stacks-java

    • Path inspected: root pom.xml (if present)
    • Notes: a meta repo in some orgs; needs per-repo check. (status: needs follow-up)

13. stacks-pact-provider-java

    • Path inspected: attempted root pom.xml (404)
    • Status: missing or layout differs; may be sample or not present.

14. java-stacks-with-micronaut

    • Path inspected: attempted pom.xml (layout differs)
    • Notes: demo/micronaut sample; exclude unless maintainers request adoption.

15. stacks-java-sample-*

    • Notes: sample/demo repos discovered during search. Skip by default.

16. (others)

    • Several additional stacks-java-* repositories were discovered but returned 404 when attempting to fetch pom.xml at the usual paths. These need per-repo follow-up to locate POMs, if present.

Next actions

• Parse the downloaded POMs to produce a per-repo structured table (groupId, artifactId, version, parent groupId, parent version).
• Mark archived and sample repos as excluded (and list their names explicitly).
• Create pilot PRs for 2–3 active repos that currently reference com.amido.stacks.modules to update to com.ensono.stacks.modules:stacks-modules-parent:3.0.94.
• Add links in this file to the precise GitHub file URLs for each inspected POM (if you want those added now, I can insert them).

If you'd like, I can now parse the poms I downloaded to produce the structured table and then open pilot PRs. Which step should I take next?

/cc @Ensono/stacks-maintainers

[RichardSlater]

stacks-modules-parent (com.ensono.stacks.modules)
├── stacks-core-commons (com.ensono.stacks.modules)
│   ├── stacks-core-cqrs (com.amido.stacks.modules)
│   ├── stacks-core-messaging (com.amido.stacks.modules)
│   │   └── stacks-azure-servicebus (com.amido.stacks.modules)
│   ├── stacks-azure-cosmos (com.amido.stacks.modules)
│   └── stacks-aws-dynamodb (com.amido.stacks.modules)
└── stacks-core-api (com.amido.stacks.modules)
    │
    ├── stacks-api (com.amido.stacks.workloads)
    │   ├── [Extends] stacks-core-api
    │   └── [Extends] stacks-core-commons
    │
    ├── stacks-api-cqrs (com.amido.stacks.workloads)
    │   ├── [Extends] stacks-core-api
    │   ├── [Extends] stacks-core-commons
    │   ├── [Extends] stacks-core-cqrs
    │   ├── [Optional] stacks-azure-cosmos (via profiles)
    │   └── [Optional] stacks-aws-dynamodb (via profiles)
    │
    └── stacks-api-cqrs-events (com.amido.stacks.workloads)
        ├── [Extends] stacks-core-api
        ├── [Extends] stacks-core-commons
        ├── [Extends] stacks-core-cqrs
        ├── [Optional] stacks-azure-cosmos (via profiles)
        ├── [Optional] stacks-aws-dynamodb (via profiles)
        └── [Optional] stacks-azure-servicebus (via profiles)