@xpertss/projen-types 0.0.25 → 0.0.26

package/.jsii

@@ -106,7 +106,7 @@
   },
   "name": "@xpertss/projen-types",
   "readme": {
-    "markdown": "# @xpertss/projen-types\n\nProjen project types for CDK/TypeScript and Java/Maven projects.\n\nInstead of hand-maintaining `pom.xml`, `cdk.json`, and GitHub workflows, you declare a project type in a `.projenrc.ts` file and let [projen](https://github.com/projen/projen) generate (and keep up to date) the whole scaffold: build files, source skeletons, CI workflows, and deploy pipelines.\n\n## Project types at a glance\n\n| Type | What it is | Publishes to | Generated workflows |\n| --- | --- | --- | --- |\n| `CdkInfraProject` | Pure-infrastructure CDK stacks (CloudFront, Route53, SQS, API Gateway, Cognito, ECR/ECS for externally-built images) | - | `build` (PR checks), `deploy` (manual dispatch) |\n| `CdkAppProject` | Full TypeScript service behind API Gateway: infra + app source + database | - | `build`, `deploy`, `app-build` (PR checks) |\n| `JavaMavenProject` | Plain Maven project, single- or multi-module, no framework | - | `build`, `upgrade` (nightly report) |\n| `JavaLibraryProject` | Reusable Java library | Maven Central | `build`, `upgrade` (nightly report), `publish-maven-central`, `codeindex` |\n| `JavaAppProject` | GUI/TUI/CLI Java application | GitHub Packages | `build`, `upgrade` (nightly report), `publish-ghpackages` |\n| `JavaSpringBootProject` | Spring Boot on Maven, single- or multi-module, **no Docker** | - | `build`, `upgrade` (nightly report) |\n| `JavaServiceProject` | Spring Boot service deployed as a container | Docker Hub | `build`, `upgrade` (nightly report), `publish-docker`, `deploy-cdk` |\n| `GitHubActionProject` | Reusable GitHub Action or Workflow | GitHub Releases | `build`, `test-dogfood`, `sonar`, `release` |\n\nThe Java types are layered, so pick the lowest layer that does what you need:\n\n```text\nJavaMavenProject            java_maven         Maven only; single- or multi-module; any supported Java line\n├── JavaLibraryProject      java_library       + Maven Central publish, source/javadoc jars, code index\n├── JavaAppProject          java_app           + GitHub Packages publish\n└── JavaSpringBootProject   java_spring_boot   + Spring Boot BOM and executable-jar repackaging; no Docker/Flyway/CDK\n    └── JavaServiceProject  java_service       + Docker publish, Flyway, CDK deploy hook (single-module)\n```\n\nEvery Java type targets a configurable Java line (`javaVersion`: `1.8`, `17`, `21` or `25`; see [Java version support](#java-version-support)), and every one except `JavaServiceProject` can be a multi-module Maven reactor (see [JavaMavenProject](#javamavenproject)).\n\nOne foundation class is also exported for advanced use: `CdkTypescriptProject` (shared CDK + TypeScript base for the CDK types).\n\nAll project types:\n\n- run a **drift check** in PR builds - a job that re-runs projen and fails if generated files were hand-edited. Edit `.projenrc.ts`, then run `npx projen`; never edit generated files directly.\n- use the GitHub secret `PROJEN_GITHUB_TOKEN` (a fine-grained PAT) for projen's automation. Override with `gheTokenSecret`.\n- make all publishing/deploying **manual** (workflow_dispatch) rather than on every merge.\n- offer an opt-in SonarCloud scan (`sonar.yml`) on any type via `sonarHostUrl` (see [SonarCloud (opt-in)](#sonarcloud-opt-in)).\n\n## Getting started\n\nHow you start depends on what is already in the directory:\n\n| Starting point | Do this |\n| --- | --- |\n| Empty directory | `projen new --from` (below) |\n| Existing repo, no `.projenrc.ts` | `projen new --from ... --no-git` (below) |\n| A `.projenrc.ts` but no `.projen/` directory - copied from another repo, or one of the [examples](#examples) pasted into a fresh repo | [Starting from an existing `.projenrc.ts`](#starting-from-an-existing-projenrcts) |\n\nScaffold the repo with projen's own bootstrap, pointed at this package:\n\n```bash\nmkdir my-project && cd my-project\ngit init\nnpx projen new --from @xpertss/projen-types cdk_infra --name my-project\n```\n\nThat writes a starter `.projenrc.ts`, synthesizes the whole scaffold and\ninstalls dependencies. The type names `projen new` accepts are `cdk_infra`,\n`cdk_app`, `java_maven`, `java_library`, `java_app`, `java_spring_boot`,\n`java_service` and `git_hub_action`; pass a bogus one to have it list them.\nRequired options become flags: `--name` for every type, plus\n`--group-id`/`--artifact-id` (Java). Any other plainly-typed option can be\npassed the same way - `--sonar-host-url` (opt-in Sonar, all types),\n`--java-version 1.8`, `--cdk-deploy-target-repo owner/repo`,\n`--docker-registry ghcr.io`, `--no-use-flyway`, and so on. Modules can't be\npassed on the command line; add them to `.projenrc.ts` afterwards (see\n[JavaMavenProject](#javamavenproject)).\n\n**Adding projen to a repo that already has content.** `projen new` runs\n`git init` and commits the scaffold by default. In a repo with existing work,\npass `--no-git` so it writes the files and leaves committing to you:\n\n```bash\ncd existing-repo\nnpx projen new --from @xpertss/projen-types java_spring_boot --name obeya --group-id org.xpertss.obeya --artifact-id obeya-parent --no-git\n```\n\n**Commit a lockfile.** The generated `build.yml` and drift check install the\ntoolchain with `npm ci`, which needs a committed `package-lock.json`, and\n`projen new` doesn't always leave one behind. Run `npm install` once and\ncommit `package-lock.json` along with the scaffold. Without it those\nworkflows fail with an `::error::` that says exactly this. For the Java\ntypes, `package.json` is generated, and it pins `projen` and\n`@xpertss/projen-types` to **exact** versions (no `^`), so every machine and\nCI run uses the same generator. A floating range would make the drift check\nreport the differences between generator versions as drift.\n\nCommit the result. From then on, every change to the scaffold goes through\n`.projenrc.ts` followed by `npx projen`:\n\n```bash\nnpx projen\n```\n\nEvery type scaffolds from that one command; no option is *required* that\n`projen new` cannot pass. The structured options - `environments` and\n`GitHubActionProject`'s `dogfood` - are ones projen's CLI cannot render\ninto a projenrc, so they are added afterwards by editing `.projenrc.ts` and\nre-running `npx projen`. Leaving `environments` out simply generates no\ndeploy workflow; leaving `dogfood` out (or a service's\n`cdkDeployTargetRepo`) still generates the workflow, with one step that\nfails and tells you what to add - a gate this package considers load-bearing\nis allowed to be missing loudly, never silently.\n\nThe `name` option must match the `name` field in the project's `package.json` (for the CDK types). For the Java types it becomes the root pom's `<name>` and the generated `package.json` name.\n\n> **Never write projen's generated-file marker text literally in `.projenrc.ts`.** projen deletes, as an orphaned generated file, any file containing the marker line (`~~ Generated by projen. To modify, ...`), and that includes `.projenrc.ts` itself. When you generate a file yourself (for example with `TextFile`), insert the marker through the file's `marker` property: ``file.addLine(`# ${file.marker}`)``.\n\n## Starting from an existing `.projenrc.ts`\n\nA directory that has a `.projenrc.ts` but no `.projen/` directory has never\nbeen synthesized. This happens when you copy the rc from another repo, or paste\none of the [examples](#examples) into a fresh repo. In that state `npx projen`\nfails with:\n\n```\n👾 Unable to find projen project. Use \"projen new\" to create a new project.\n```\n\n`npx projen` doesn't run `.projenrc.ts` itself. It runs the `default` task\nlisted in `.projen/tasks.json`, and that file is written by the first synth.\nDo the first synth one of these two ways. After that, `npx projen` works as\nusual.\n\n**Option 1 (recommended): run `projen new` over the existing rc.** `projen\nnew` leaves an existing `.projenrc.ts` untouched and writes the rest of the\nscaffold, `.projen/` included. Pass the type and its required flags as you\nwould for a new repo. Their values don't have to match your rc, because the\n`npx projen` that follows re-synthesizes everything from the rc:\n\n```bash\nnpx projen new --from @xpertss/projen-types git_hub_action --name pull-request --sonar-host-url https://sonarcloud.io --no-git\nnpx projen\n```\n\nThe first command's output reflects only the flags. For example, a\n`GitHubActionProject`'s `test-dogfood.yml` is still the failing placeholder.\nThe second command applies everything in the rc (`dogfood`, `environments`,\nmodules, and so on).\n\n**Option 2 (Java types and `GitHubActionProject`): run the rc directly,\nonce.** The CDK types run their rc differently, so for those use option 1.\nInstall what the rc imports, give\nts-node a placeholder `tsconfig.projen.json` (the synth overwrites it with the\ngenerated one), and run the same command the generated `default` task runs:\n\n```bash\nnpm i -D projen @xpertss/projen-types constructs\necho '{}' > tsconfig.projen.json\nnpx -y -p ts-node@10.9.2 -p typescript@6.0.3 ts-node --project tsconfig.projen.json .projenrc.ts\nnpx projen\n```\n\nThe `echo` line works in bash and PowerShell. Don't drop `--project`: without\na tsconfig, ts-node fails on Node 22+ with `Unknown file extension \".ts\"`.\n\nEither way, commit `.projen/` along with the rest of the scaffold. A fresh\nclone then has its `tasks.json`, and `npx projen` works there straight away.\n\n## Updating an existing project when this package changes\n\nYour generated scaffold reflects the *installed* version of `@xpertss/projen-types` - `npx projen` reads your project type from the package in `node_modules`, not from this repository. So when this package ships a change (a bug fix, a new generated file, or altered workflow behavior), an existing project picks it up by bumping the dependency and re-synthesizing. A stale `node_modules` silently regenerates with the old behavior, so the bump is the load-bearing step.\n\nUsing the [`auto-commit` action](#githubactionproject) as a running example, say a new release adds the `# Purpose:` workflow header and SonarCloud wording. In the `auto-commit` repo:\n\n```bash\nnpm view @xpertss/projen-types version        # what's the newest release?\nnpm i -D @xpertss/projen-types@latest         # bump the installed project type\nnpx projen                                    # re-synthesize every generated file\ngit diff                                      # review before committing\n```\n\nThe diff here is the workflows gaining a `# Purpose:` comment and `sonar.yml` reflecting the SonarCloud wording. Commit the result with a normal `chore:` or `fix:` message - you never hand-edit the generated files themselves.\n\n## Examples\n\nEach example shows the `projen new` command first, then a fuller\n`.projenrc.ts`. Run the command first, then replace the generated\n`.projenrc.ts` with the example (or merge it in) and run `npx projen`. If you\npasted the example into a fresh repo first instead, see\n[Starting from an existing `.projenrc.ts`](#starting-from-an-existing-projenrcts).\n\n### CdkInfraProject\n\nPure infrastructure stacks with optional ECR/ECS and edge-networking constructs.\n\nScaffold it with the `cdk_infra` type:\n\n```bash\nnpx projen new --from @xpertss/projen-types cdk_infra --name media-edge-infra\n```\n\n```typescript\n// .projenrc.ts\nimport { CdkInfraProject } from '@xpertss/projen-types';\n\nconst project = new CdkInfraProject({\n  name: 'media-edge-infra',\n  environments: [\n    'dev',\n    { name: 'stage', accountId: '111111111111', region: 'eu-central-1' },\n    { name: 'prod', accountId: '222222222222', region: 'eu-central-1', requiresApproval: true },\n  ],\n  edgeResources: ['cloudfront', 'route53', 'sqs'],\n  ecrEcs: { enabled: true, externalImageSource: true },\n});\n\nproject.synth();\n```\n\nYou get:\n\n- `cdk.json`, `cdk synth` / `cdk diff` / `cdk deploy` tasks, and the standard `AwsCdkTypeScriptApp` layout (CDK 2.189.1 by default).\n- `.github/workflows/build.yml` - PR build that hard-fails on projen drift.\n- `.github/workflows/deploy.yml` - manual dispatch with one `deploy-<env>` job per environment (runs `cdk deploy --all` with `--context environment=<env>`); `requiresApproval` environments get a GitHub Environment approval gate.\n- `LICENSE` (MIT by default), `.editorconfig`, and the projen drift check.\n- `src/constructs/edge-networking.ts` - helper constructs only for the requested `edgeResources` (`cloudfront`, `route53`, `apigateway`, `cognito`, `sqs`).\n- `src/constructs/ecr-ecs.ts` when `ecrEcs.enabled` - ECR repo + Fargate service; `externalImageSource: true` (default) means the service pulls an image built outside this repo.\n\n### CdkAppProject\n\n`CdkInfraProject` plus application source, a database construct, and an app-level build workflow.\n\nScaffold it with the `cdk_app` type:\n\n```bash\nnpx projen new --from @xpertss/projen-types cdk_app --name video-api\n```\n\n```typescript\n// .projenrc.ts\nimport { CdkAppProject } from '@xpertss/projen-types';\n\nconst project = new CdkAppProject({\n  name: 'video-api',\n  environments: ['dev', 'prod'],\n  edgeResources: ['apigateway'],\n  database: { engine: 'postgres', migrationTool: 'flyway' },\n  appEntryPoint: 'src/app.ts',\n});\n\nproject.synth();\n```\n\nEverything from `CdkInfraProject`, plus:\n\n- `src/app.ts` - application entrypoint stub (`export function handler()`).\n- `src/handlers/example.ts` - API Gateway proxy handler stub, with `@types/aws-lambda` added as a dev dependency.\n- `src/constructs/database.ts` - a `Database` construct stub for the chosen engine (`postgres`/`mysql` -> RDS, `dynamodb` -> DynamoDB). `migrationTool` (no default, intentionally) is added as a dev dependency and referenced in the stub - wiring it up is left to you.\n- `.github/workflows/app-build.yml` - runs the project's test task on every PR, then checks for projen drift.\n\n### JavaMavenProject\n\nA plain Maven build with no framework and no publish target. It's the base of every other Java type, and it's usable on its own. It's single-module until you add a module, then it's a multi-module reactor.\n\nScaffold it with the `java_maven` type:\n\n```bash\nnpx projen new --from @xpertss/projen-types java_maven --name legacy-tools --group-id org.xpertss --artifact-id legacy-tools --java-version 1.8\n```\n\n**Single module:**\n\n```typescript\n// .projenrc.ts\nimport { JavaMavenProject } from '@xpertss/projen-types';\n\nconst project = new JavaMavenProject({\n  name: 'legacy-tools',\n  groupId: 'org.xpertss',\n  artifactId: 'legacy-tools',\n  javaVersion: '1.8',\n});\n\nproject.addDependency('commons-io/commons-io@2.20.0');    // exact version\nproject.addTestDependency('org.assertj/assertj-core@3.27.3');\n\nproject.synth();\n```\n\n**Multi-module:** each `addModule()` call adds a module directory with its own generated `pom.xml`. The root pom becomes the `pom`-packaged reactor parent. Everything stays one projen project, with one `.projen/`, one `.gitignore` and one `tasks.json`.\n\n```typescript\n// .projenrc.ts\nimport { JavaMavenProject } from '@xpertss/projen-types';\n\nconst project = new JavaMavenProject({\n  name: 'toolkit',\n  groupId: 'org.xpertss.toolkit',\n  artifactId: 'toolkit-parent',\n  version: '0.1.0-SNAPSHOT',\n  javaVersion: '17',\n});\n\nconst model = project.addModule({ dir: 'toolkit-model', artifactId: 'toolkit-model', description: 'Domain model' });\nconst stub = project.addModule({ dir: 'tools/stub-model', artifactId: 'toolkit-stub-model' }); // nested dirs are fine\nconst cli = project.addModule({ dir: 'toolkit-cli', artifactId: 'toolkit-cli' });\n\nstub.addModuleDependency(model);                     // sibling module: versionless\ncli.addModuleDependency(model);\ncli.addDependency('info.picocli/picocli@4.7.7');     // pinned: the version moves to the parent\ncli.addDependency('org.yaml/snakeyaml');             // versionless: managed below\nproject.addManagedDependency('org.yaml/snakeyaml@2.4');\nproject.addBom('org.testcontainers/testcontainers-bom@1.21.3');\n\nproject.synth();\n```\n\nWhat the reactor looks like:\n\n- **Root `pom.xml`:**\n  - `<packaging>pom</packaging>`, with `<modules>` in `addModule` order.\n  - `<dependencyManagement>` holds the BOM imports first (`type=pom`, `scope=import`), then every module at `${project.version}`, then every pinned version.\n  - `<pluginManagement>` holds the plugin versions, and versionless `<plugins>` are inherited by every module: compiler, surefire, failsafe, jar, and enforcer.\n  - `junit-jupiter` is a test dependency every module inherits. Its version comes from `junit-bom`, or from the Spring Boot BOM in the Spring Boot types.\n- **Module `pom.xml`:** `<parent>` with the right `relativePath` (`tools/stub-model` → `../../pom.xml`), then `artifactId`, `name`, `description`, and versionless `<dependencies>`. Nothing else, unless the module adds plugins.\n- A version given to `module.addDependency`/`addTestDependency`/`addPlugin` is moved into the parent's `<dependencyManagement>`/`<pluginManagement>`, so every module that uses an artifact gets the same version. Pinning one artifact at two different versions fails the synth.\n- The synth fails with a clear message on:\n  - two modules with the same `artifactId`\n  - two modules with the same `dir`, or one `dir` nested inside another\n  - a `dir` outside the repo\n  - a module depending on itself\n  - `packaging` set to anything but `pom` on a project with modules\n\nYou get:\n\n- the root `pom.xml` (and one per module), written by this package:\n  - **exact versions only**: a range such as `^1`, `~1.2` or `[1,2)` fails the synth\n  - the compiler level, enforcer rule and JUnit line all follow `javaVersion`\n- one Maven run per build. `npx projen build` synthesizes, then runs `mvn -B verify`: compile, unit tests (surefire), package, and `*IT` integration tests (failsafe). There is no `mvn deploy` and no `dist/`.\n- `.github/workflows/build.yml`: a PR build that installs the pinned Node toolchain (`npm ci`) and the project's JDK (`actions/setup-java`, Maven cache), then runs `npx projen build`. The Maven build itself never runs a Sonar step - SonarCloud scanning is a separate, opt-in `sonar.yml` (set `sonarHostUrl`). See [Adding CI jobs](#adding-ci-jobs-to-a-java-project) and [SonarCloud (opt-in)](#sonarcloud-opt-in).\n- `.github/workflows/upgrade.yml`: a nightly (03:00 UTC) **report** of available dependency and plugin updates in the job summary. It changes nothing, because every version comes from `.projenrc.ts`; apply an update there. Turn it off with `upgradeWorkflow: false`. The same report runs locally with `npx projen upgrade`.\n- the projen drift check, `LICENSE` (MIT by default), `.editorconfig`, and a generated `package.json` that pins the projen toolchain exactly.\n- no sample code, unless `sample: true` on a single-module project.\n\n### JavaLibraryProject\n\nA reusable Java library published to Maven Central.\n\nScaffold it with the `java_library` type:\n\n```bash\nnpx projen new --from @xpertss/projen-types java_library --name common-utils --group-id org.xpertss --artifact-id common-utils\n```\n\n```typescript\n// .projenrc.ts\nimport { JavaLibraryProject } from '@xpertss/projen-types';\n\nconst project = new JavaLibraryProject({\n  name: 'common-utils',\n  groupId: 'org.xpertss',\n  artifactId: 'common-utils',\n  version: '1.0.0',\n  sonarHostUrl: 'https://sonarcloud.io',   // opt-in: adds sonar.yml (see SonarCloud)\n  mavenCentralOidc: true,\n});\n\nproject.synth();\n```\n\nYou get everything from [`JavaMavenProject`](#javamavenproject), so modules work here too, plus:\n\n- `maven-source-plugin` and `maven-javadoc-plugin`, attaching the `-sources`/`-javadoc` jars Maven Central requires. In a multi-module library every module attaches them.\n- `.github/workflows/publish-maven-central.yml` - manual dispatch running `mvn -B deploy -P release`. With `mavenCentralOidc: true` it uses Maven Central's OIDC trusted publishing (no GPG secrets needed); otherwise it expects the secrets `MAVEN_GPG_PRIVATE_KEY`, `MAVEN_GPG_PASSPHRASE`, `MAVEN_CENTRAL_USERNAME`, `MAVEN_CENTRAL_PASSWORD`.\n- `.github/workflows/codeindex.yml` - on push to `main`, generates a Java source index under `.cai/` covering every module (disable with `publishCodeIndex: false`).\n\n### JavaSpringBootProject\n\nSpring Boot on Maven, single- or multi-module, **without** Docker, Flyway or a deploy hook. It's [`JavaMavenProject`](#javamavenproject) plus Spring Boot dependency management. Use it for a Spring Boot repo that ships something other than this package's container image, such as a multi-module control plane, or for a Boot app you deploy your own way.\n\nScaffold it with the `java_spring_boot` type:\n\n```bash\nnpx projen new --from @xpertss/projen-types java_spring_boot --name obeya --group-id org.xpertss.obeya --artifact-id obeya-parent\n```\n\n```typescript\n// .projenrc.ts\nimport { JavaSpringBootProject } from '@xpertss/projen-types';\n\nconst project = new JavaSpringBootProject({\n  name: 'obeya',\n  groupId: 'org.xpertss.obeya',\n  artifactId: 'obeya-parent',\n  version: '0.1.0-SNAPSHOT',\n  javaVersion: '21',\n  copyrightOwner: 'Xpert Software',\n});\n\n// plain jar modules: shared libraries, clients, tools\nconst model = project.addModule({ dir: 'obeya-model', artifactId: 'obeya-model' });\nconst client = project.addModule({ dir: 'obeya-api-client', artifactId: 'obeya-api-client' });\nclient.addModuleDependency(model);\n\n// a Spring Boot application module, repackaged into an executable jar\nconst server = project.addSpringBootModule({ dir: 'obeya-server', artifactId: 'obeya-server' });\nserver.addModuleDependency(model);\nserver.addDependency('org.springframework.boot/spring-boot-starter-web');      // versionless: Boot's BOM manages it\nserver.addTestDependency('org.springframework.boot/spring-boot-starter-test');\n\nproject.addBom('org.testcontainers/testcontainers-bom@1.21.3');\n\nproject.synth();\n```\n\nYou get everything from [`JavaMavenProject`](#javamavenproject), plus:\n\n- `spring-boot-dependencies` imported as the **first** BOM, so starters and every library Boot manages (JUnit included) are added without a version. `springBootVersion` sets it; the default is the newest release of the line that supports `javaVersion` (see [Java version support](#java-version-support)).\n- `spring-boot-maven-plugin`, versioned in `<pluginManagement>`:\n  - In a **single-module** project the root jar is repackaged into an executable jar.\n  - In a **multi-module** project only modules added with `addSpringBootModule()` are repackaged; `addModule()` modules stay plain jars.\n  - A repackaged module needs its `@SpringBootApplication` class before `mvn verify` passes, because `repackage` fails with `Unable to find main class` until one exists. Add a module as a plain `addModule()` while it's still empty.\n- failsafe configured to run integration tests against the compiled classes rather than the repackaged jar (as `spring-boot-starter-parent` does).\n- no starters, no Docker, no Flyway, no CDK. Add the starters you need with `addDependency`.\n\n### JavaServiceProject\n\nA Spring Boot service that publishes a Docker image and can trigger deploys in a companion CDK repo. It is [`JavaSpringBootProject`](#javaspringbootproject) plus Docker, Flyway and a deploy hook. It is **single-module**, because the Docker build, the migrations and the deploy hook all assume one deployable at the repo root; `addModule()` fails and points you to `JavaSpringBootProject`.\n\nScaffold it with the `java_service` type:\n\n```bash\nnpx projen new --from @xpertss/projen-types java_service --name stream-processor --group-id org.xpertss --artifact-id stream-processor\n```\n\n```typescript\n// .projenrc.ts\nimport { JavaServiceProject } from '@xpertss/projen-types';\n\nconst project = new JavaServiceProject({\n  name: 'stream-processor',\n  groupId: 'org.xpertss',\n  artifactId: 'stream-processor',\n  dockerRegistry: 'docker.io/xpertss',\n  cdkDeployTargetRepo: 'xpertss/stream-infra',\n  environments: ['dev', { name: 'prod', requiresApproval: true }],\n});\n\nproject.synth();\n```\n\nYou get everything from [`JavaSpringBootProject`](#javaspringbootproject) (and so from `JavaMavenProject`), plus:\n\n- `spring-boot-starter-web` added to the pom (versionless; Boot's BOM manages it).\n- `.github/workflows/publish-docker.yml` - manual dispatch: `mvn -B package && docker build -t <registry>/<name>:<sha>`, logged in with the `DOCKER_USERNAME` / `DOCKER_PASSWORD` secrets. `dockerRegistry` defaults to `docker.io`.\n- Flyway wiring when `useFlyway` (default `true`): `flyway-core` (versionless, so it matches what Boot's Flyway auto-configuration expects), `flyway-maven-plugin` pinned for the Java line, and `src/main/resources/db/migration/V1__init.sql`.\n- `.github/workflows/deploy-cdk.yml` (the `CdkDeployHook`, generated by default) - manual dispatch with an environment selector; each job sends a `workflow_dispatch` to `deploy.yml` in the companion `cdkDeployTargetRepo` (a `CdkInfraProject`/`CdkAppProject` repo). With no `cdkDeployTargetRepo` set, the workflow is still generated but each job's only step fails with instructions - it is dispatch-only, so that lands on whoever tries to deploy rather than on every PR. Turn the workflow off entirely with `cdkDeployHook: false`. `environments` defaults to `['prod']`.\n\n### JavaAppProject\n\nA GUI/TUI/CLI Java application published to GitHub Packages only - no Maven Central, no Docker, no CDK deploy hook.\n\nScaffold it with the `java_app` type:\n\n```bash\nnpx projen new --from @xpertss/projen-types java_app --name studio-cli --group-id org.xpertss --artifact-id studio-cli\n```\n\n```typescript\n// .projenrc.ts\nimport { JavaAppProject } from '@xpertss/projen-types';\n\nconst project = new JavaAppProject({\n  name: 'studio-cli',\n  groupId: 'org.xpertss',\n  artifactId: 'studio-cli',\n  ghPackagesRegistry: 'https://maven.pkg.github.com/xpertss/studio-cli',\n});\n\nproject.synth();\n```\n\nYou get everything from [`JavaMavenProject`](#javamavenproject) (modules included), plus `.github/workflows/publish-ghpackages.yml` - manual dispatch running `mvn -B deploy -DaltDeploymentRepository=github::<registry>`, authenticated with `GITHUB_TOKEN`. `ghPackagesRegistry` defaults to `https://maven.pkg.github.com/<repo>` derived from the repository URL.\n\n### GitHubActionProject\n\nA reusable GitHub Action or Workflow. This example scaffolds an action that stages a folder and, only if it changed, commits and pushes it.\n\nScaffold it with the `git_hub_action` type:\n\n```bash\nnpx projen new --from @xpertss/projen-types git_hub_action --name auto-commit --sonar-host-url https://sonarcloud.io\n```\n\n```typescript\n// .projenrc.ts\nimport { GitHubActionProject } from '@xpertss/projen-types';\n\nconst project = new GitHubActionProject({\n  name: 'auto-commit',\n  description: 'Stage a folder and, only if it changed, commit and push it',\n  sonarHostUrl: 'https://sonarcloud.io',       // optional - set it to add sonar.yml (see SonarCloud)\n  sonarOrganization: 'xpertss',                 // default - your SonarCloud org key\n  dogfood: {\n    // Two scenario steps: the \"changed\" path and the \"no-op\" path are both\n    // load-bearing behavior for this action (a double-commit or a\n    // push-when-empty bug is the failure mode a hand-rolled inline-shell\n    // alternative is most likely to introduce).\n    scenario: [\n      {\n        name: 'Changed path',\n        fixtureSteps: [\n          'echo \"$(date -u +%Y%m%dT%H%M%SZ)\" >> test/fixtures/dogfood-state.txt',\n        ],\n        inputs: {\n          commit_message: 'test: dogfood',\n          branches: 'test/dogfood',\n        },\n        assertions: [\n          // step id defaults to a slug of `name` - here \"changed-path-0\"\n          '[ \"${{ steps.changed-path-0.outputs.committed }}\" = \"true\" ]',\n        ],\n      },\n      {\n        // No fixture change this time - nothing new to commit.\n        name: 'No-op path',\n        id: 'no-op-check',            // pin an explicit id instead of relying on the default slug\n        inputs: {\n          commit_message: 'test: dogfood',\n          branches: 'test/dogfood',\n        },\n        assertions: [\n          '[ \"${{ steps.no-op-check.outputs.committed }}\" = \"false\" ]',\n        ],\n      },\n    ],\n    cleanup: [\n      'git push origin --delete test/dogfood || true',\n    ],\n  },\n});\n\nproject.synth();\n```\n\nYou get:\n\n- `action.yml` and `auto-commit.sh` are hand-written - this type only lints their content via `build.yml`'s shellcheck/yamllint/actionlint checks.\n- `.github/workflows/build.yml` - lint gate: `apt`-installed shellcheck/yamllint plus a pinned, SHA-256-verified `actionlint` release binary. Gates `main` (alongside `sonar.yml` when Sonar is enabled).\n- `.github/workflows/test-dogfood.yml` - runs the `dogfood.scenario` steps above against this repo's own `action.yml` (via `uses: ./`), then the shared `cleanup`, on `workflow_dispatch`, every `pull_request`, and nightly. Omit `dogfood` and the workflow still exists, with one step that fails on every PR until you declare a scenario - AD-001 allows a dogfood to be missing loudly, never silently. A *partial* `dogfood` (a scenario with no cleanup) is a synth error.\n- `.github/workflows/sonar.yml` - SonarCloud scan via the Scanner CLI (the quality gate blocks the PR), scanning `action.yml`/`.github/workflows/**`/`**/*.sh` explicitly. Opt-in: generated only when `sonarHostUrl` is set (see [SonarCloud (opt-in)](#sonarcloud-opt-in)).\n- `.github/workflows/release.yml` - `feat:`/`fix:` commits on `main` bump the version, tag `vX.Y.Z`, and create a GitHub Release.\n- `.github/workflows/projen-drift-check.yml` and `workflow-change-notice.yml` - drift detection and a change notice, always included.\n- `package.json` (**private**, version source only), `.yamllint`, `LICENSE` (MIT by default), and a `README.md` template - all regenerated by `npx projen`.\n\nNeeds `PROJEN_GITHUB_TOKEN` (used for automated PR comments), and `SONAR_TOKEN` only when Sonar is enabled (see [SonarCloud (opt-in)](#sonarcloud-opt-in)). Onboard a brand-new action repo by running the `projen new` command above first (see [Getting started](#getting-started)), then replace the generated `.projenrc.ts` with the one above and run `npx projen`, then hand-write `action.yml`/`auto-commit.sh`/`test/fixtures/`. If you wrote the `.projenrc.ts` before running `projen new`, see [Starting from an existing `.projenrc.ts`](#starting-from-an-existing-projenrcts).\n\n## Java version support\n\n`javaVersion` picks the Java line a Java project targets. It defaults to `21`; the supported lines are `1.8` (alias `8`), `17`, `21` and `25`, and any other value fails the synth with that list. **Nothing in the generated build is hard-coded to one Java line.** Everything that depends on it comes from one table in this package, grouped by line:\n\n| | `1.8` | `17` | `21` | `25` |\n| --- | --- | --- | --- | --- |\n| Compiler level | `maven.compiler.source`/`target` = `1.8` (javac 8 has no `--release`) | `maven.compiler.release` = `17` | `release` = `21` | `release` = `25` |\n| Enforcer `requireJavaVersion` | `[1.8,)` | `[17,)` | `[21,)` | `[25,)` |\n| JUnit (`junit-bom`) | 5.14.4 (JUnit 6 needs Java 17) | 6.1.3 | 6.1.3 | 6.1.3 |\n| Default Spring Boot (`JavaSpringBootProject`) | 2.7.18 (Boot 3+ needs Java 17; a 3.x+ `springBootVersion` fails the synth) | 4.1.1 | 4.1.1 | 4.1.1 |\n| `flyway-maven-plugin` (`JavaServiceProject`) | 9.22.3 | 13.9.0 | 13.9.0 | 13.9.0 |\n| CI JDK (`actions/setup-java` `java-version`) | `8` | `17` | `21` | `25` |\n\nMaven plugins (the same on every line, because all of them run on JDK 8): `maven-compiler-plugin` 3.16.0, `maven-surefire-plugin`/`maven-failsafe-plugin` 3.6.0, `maven-jar-plugin` 3.5.1, `maven-enforcer-plugin` 3.6.3, `maven-source-plugin` 3.4.0 and `maven-javadoc-plugin` 3.12.0 (library only), `versions-maven-plugin` 2.22.0 (the `upgrade` report).\n\n**The enforcer.** `maven-enforcer-plugin` fails the build at the start when the JDK or Maven running it is older than the project needs. Without it you get confusing compiler errors later, or a jar built for the wrong runtime. Its Java rule always follows `javaVersion`. The Maven rule defaults to `[3.9,)`; change it with `minMavenVersion`, or drop the plugin entirely with `enforcer: false`. CI installs the matching JDK through `setup-java`, so the rule only fires on a developer machine with the wrong JDK. A Java 1.8 project builds on any newer JDK (the rule is a minimum), but the JDK 8 runtime API is guaranteed only when you build on JDK 8.\n\n**Overriding a version.** `pluginVersions` replaces any default in the table, keyed by `groupId/artifactId`, with an exact version:\n\n```typescript\nnew JavaMavenProject({\n  name: 'svc',\n  groupId: 'org.xpertss',\n  artifactId: 'svc',\n  pluginVersions: {\n    'org.apache.maven.plugins/maven-surefire-plugin': '3.5.6',\n    'org.junit/junit-bom': '5.14.4',\n  },\n});\n```\n\n`project.pinnedVersion('org.apache.maven.plugins/maven-surefire-plugin')` returns the version in effect, for reuse in your own plugin config.\n\n**New Java lines** are one new row in this package's version table and a release. Until a line is listed, `javaVersion` rejects it rather than guessing.\n\n## Adding CI jobs to a Java project\n\n`build.yml` is exposed as `project.buildVerifyWorkflow`, so jobs are added through projen's `addJob` rather than `addOverride`. `project.ciSetupSteps` holds the steps every Maven job here needs: pinned Node, `npm ci`, and the project's JDK with a Maven cache. Every job in `build.yml` can then be made a required check on `main`.\n\n```typescript\nimport { github } from 'projen';\n\nproject.buildVerifyWorkflow.addJob('integration', {\n  name: 'Container integration tests',\n  runsOn: ['self-hosted', 'linux', 'fedora', 'podman'],\n  permissions: { contents: github.workflows.JobPermission.READ },\n  steps: [\n    { name: 'Checkout', uses: 'actions/checkout@v7' },\n    ...project.ciSetupSteps,\n    { name: 'Integration tests', run: 'mvn -B verify -Pcontainer-its' },\n  ],\n});\n```\n\n## Common options\n\nCDK project types (`CdkInfraProjectOptions` / `CdkAppProjectOptions`):\n\n| Option | Default | Description |\n| --- | --- | --- |\n| `name` | - (required) | Project name; must match `package.json` |\n| `cdkVersion` | `2.189.1` | AWS CDK version |\n| `gheTokenSecret` | `PROJEN_GITHUB_TOKEN` | GitHub secret holding projen's PAT |\n| `licensed` | `true` | Write a `LICENSE` |\n| `license` | `MIT` | SPDX identifier for the `LICENSE` |\n| `copyrightOwner` / `copyrightPeriod` | `Xpert Software` / current year | Named in the `LICENSE` |\n| `environments` | - (no `deploy` workflow) | Deploy targets for the `deploy` workflow; strings or `EnvironmentOptions` |\n| `ecrEcs` | - | `EcrEcsOptions` - `enabled`, `externalImageSource` (default `true`) |\n| `edgeResources` | - | Subset of `cloudfront`, `route53`, `apigateway`, `cognito`, `sqs` |\n| `database` | - (app only) | `DatabaseOptions` - `engine` (`postgres`/`mysql`/`dynamodb`, default `postgres`), `migrationTool` |\n| `appEntryPoint` | `src/app.ts` (app only) | Path of the generated application entrypoint |\n\nJava project types (`JavaMavenProjectOptions` and everything built on it - `JavaLibraryProjectOptions`, `JavaAppProjectOptions`, `JavaSpringBootProjectOptions`, `JavaServiceProjectOptions`):\n\n| Option | Default | Description |\n| --- | --- | --- |\n| `name` | - (required) | Project name |\n| `groupId` | - (required) | Maven group id |\n| `artifactId` | - (required) | Maven artifact id (of the reactor parent, in a multi-module project) |\n| `version` | `0.1.0` | Maven version; must be exact |\n| `description` / `url` | - | Written to the root pom |\n| `javaVersion` | `21` | Java line: `1.8`, `17`, `21`, `25` - see [Java version support](#java-version-support) |\n| `javaDistribution` | `temurin` | `actions/setup-java` distribution for CI |\n| `packaging` | `jar` | Root packaging while the project has no modules; a project with modules is always `pom` |\n| `sample` | `false` | Starter `Main` + test under the `groupId` package (single-module only) |\n| `enforcer` | `true` | `maven-enforcer-plugin` with Maven and Java version rules |\n| `minMavenVersion` | `3.9` | The enforcer's `requireMavenVersion` minimum |\n| `pluginVersions` | - | Exact-version overrides for this package's defaults, keyed by `groupId/artifactId` |\n| `licensed` | `true` | Write a `LICENSE` |\n| `license` | `MIT` | SPDX identifier for the `LICENSE` |\n| `copyrightOwner` / `copyrightPeriod` | `Xpert Software` / current year | Named in the `LICENSE` |\n| `editorconfig` | `true` | Write a projen-managed `.editorconfig` (also on the CDK and action types) |\n| `upgradeWorkflow` | `true` | Generate the nightly update report (`upgrade.yml`) |\n| Sonar options | - | `sonarHostUrl`, `sonarOrganization`, `sonarTokenSecret`, `sonarPullRequestGate`, `sonarProjectKey` - SonarCloud is opt-in; see [SonarCloud (opt-in)](#sonarcloud-opt-in) |\n| `gheTokenSecret` | `PROJEN_GITHUB_TOKEN` | GitHub secret holding projen's PAT |\n| `springBootVersion` | newest Boot for `javaVersion` (Spring Boot types only) | Exact Spring Boot version: the BOM and `spring-boot-maven-plugin` |\n| `cdkDeployTargetRepo` | - (service only; `deploy-cdk.yml` fails until set) | Companion CDK repo (`owner/repo`) whose `deploy.yml` the deploy hook dispatches |\n| `cdkDeployHook` | `true` (service only) | Whether to generate `deploy-cdk.yml` at all |\n| `dockerRegistry` | `docker.io` (service only) | Registry the Docker image is pushed to |\n| `useFlyway` | `true` (service only) | Flyway plugin/dependency + `V1__init.sql` |\n\nWith the default MIT license, the generated `LICENSE` looks like:\n\n```\nMIT License\n\nCopyright (c) 2024-2026 Xpert Software\n\nPermission is hereby granted, ...\n```\n\nThe header line (`MIT License`) is specific to the license type — an `Apache-2.0` project would instead show `Apache-2.0`.\n\nOverride the license type and copyright fields:\n\n```typescript\nnew JavaMavenProject({\n  name: 'my-lib',\n  groupId: 'org.xpertss',\n  artifactId: 'my-lib',\n  license: 'Apache-2.0',            // any SPDX id projen ships a template for\n  copyrightOwner: 'Xpert Software',\n  copyrightPeriod: '2024-2026',\n});\n```\n\n`EnvironmentOptions` for deploy targets:\n\n```text\ninterface EnvironmentOptions {\n  readonly name: string;              // e.g. \"dev\", \"stage\", \"prod\"\n  readonly accountId?: string;        // AWS account id (CDK deploys)\n  readonly region?: string;           // AWS region (CDK deploys)\n  readonly requiresApproval?: boolean; // GitHub Environment approval gate (default false)\n}\n```\n\nPlain strings (`'dev'`) are shorthand for `{ name: 'dev' }`.\n\n`GitHubActionProjectOptions`:\n\n| Option | Default | Description |\n| --- | --- | --- |\n| `name` | - (required) | Project name |\n| `description` | - | One-line description; used in the default README template and recorded in the private `package.json` |\n| Sonar options | - | `sonarHostUrl`, `sonarOrganization`, `sonarTokenSecret`, `sonarPullRequestGate`, `sonarProjectKey` - SonarCloud is opt-in; see [SonarCloud (opt-in)](#sonarcloud-opt-in) |\n| `dogfood` | - (a `test-dogfood.yml` that fails until you declare one) | `ActionDogfoodOptions` - the scenario that exercises the action end-to-end via `uses: ./` |\n| `license` | `MIT` | SPDX identifier for the generated `LICENSE` |\n| `copyrightOwner` / `copyrightPeriod` | `Xpert Software` / current year | Named in the `LICENSE` |\n| `gheTokenSecret` | `PROJEN_GITHUB_TOKEN` | GitHub secret holding projen's PAT (drift-check PR comments); a dogfood that passes a `token` input must reference this secret in the step's `inputs` |\n\n`ActionDogfoodOptions`/`ActionDogfoodStep` - the dogfood scenario (`test-dogfood.yml`):\n\n```text\ninterface ActionDogfoodOptions {\n  readonly scenario: ActionDogfoodStep[]; // one or more, run in order - required\n  readonly cleanup: string[];             // shared, run once at the end with `if: always()` - required\n}\n\ninterface ActionDogfoodStep {\n  readonly name: string;                    // labels this step-group's generated workflow steps\n  readonly id?: string;                     // step id for the `uses: ./` call; default: a slug of `name`\n  readonly fixtureSteps?: string[];         // shell, before the invocation (default: none)\n  readonly inputs?: Record<string, string>; // `with:` for this invocation (default: none)\n   readonly assertions: string[];            // shell, after the invocation - required; the step runs under set -euo pipefail so any failing line fails the job\n}\n```\n\nMost actions need exactly one `scenario` step. Actions with a re-run/no-op/idempotency behavior to verify (e.g. `auto-commit`'s no-op-on-no-change path, `create-pull-request`'s reuse-the-PR path) declare two - the second typically omits `fixtureSteps` so its invocation sees no new state, and its assertion checks the opposite outcome of the first. Reference an invocation's own outputs from a later assertion via `${{ steps.<id>.outputs.<name> }}`, using either the default slug or an explicit `id`.\n\n## SonarCloud (opt-in)\n\nSonarCloud is a shared, **opt-in** capability on every project type (CDK, Java, and GitHub Action). Set `sonarHostUrl` on any type and it generates a `.github/workflows/sonar.yml` that runs a pinned, SHA-256-verified Sonar Scanner CLI and blocks the PR on the quality gate. Omit it and no `sonar.yml` is generated. The Maven build itself never runs a Sonar step.\n\nShared options (accepted by the CDK types, every Java type, and `GitHubActionProject`):\n\n| Option | Default | Description |\n| --- | --- | --- |\n| `sonarHostUrl` | - (required to enable) | URL of your SonarCloud instance (e.g. `https://sonarcloud.io`); must be reachable from github.com-hosted runners |\n| `sonarOrganization` | `xpertss` | SonarCloud org key (`sonar.organization`); required by the Scanner CLI, not derived from the token |\n| `sonarProjectKey` | `${sonarOrganization}_${name}` | `sonar.projectKey` - the org + project key SonarCloud uses (e.g. `xpertss_create-pull-request`) |\n| `sonarTokenSecret` | `SONAR_TOKEN` | GitHub secret holding the Sonar token |\n| `sonarPullRequestGate` | `true` | Whether `sonar.yml` also runs on `pull_request` as a pass/fail gate |\n\nInclusions differ by type: a `GitHubActionProject` scans `action.yml`/`.github/workflows/**`/`**/*.sh` explicitly (YAML and shell are not in Sonar's default-recognized set), while the CDK and Java types rely on Sonar's default inclusions for their languages.\n\n```typescript\nnew CdkInfraProject({\n  name: 'my-infra',\n  environments: ['dev', 'prod'],\n  sonarHostUrl: 'https://sonarcloud.io',   // adds sonar.yml\n});\n```\n\nRequires the `SONAR_TOKEN` secret (rename it with `sonarTokenSecret`).\n\n## Required GitHub secrets\n\n| Secret | Used by | Notes |\n| --- | --- | --- |\n| `PROJEN_GITHUB_TOKEN` | all types | PAT for projen's self-mutation/automation; override via `gheTokenSecret` |\n| `SONAR_TOKEN` | any type with `sonarHostUrl` set | SonarCloud scan in `sonar.yml`; override the secret name via `sonarTokenSecret` |\n| `DOCKER_USERNAME` / `DOCKER_PASSWORD` | `JavaServiceProject` | Docker image push |\n| `MAVEN_GPG_PRIVATE_KEY`, `MAVEN_GPG_PASSPHRASE`, `MAVEN_CENTRAL_USERNAME`, `MAVEN_CENTRAL_PASSWORD` | `JavaLibraryProject` without `mavenCentralOidc` | Not needed with OIDC trusted publishing |\n\n## Customizing `.gitignore`\n\nEvery project type already ignores JetBrains IDE state (`/.idea/*`) and the `/spec/` directory with all of its subdirectories (local plans and specs, never committed). The Java types also ignore Maven `target/` output and Eclipse files. To ignore more, call the inherited `addGitIgnore()` method after constructing the project in your `.projenrc.ts`:\n\n```typescript\n// .projenrc.ts\nimport { CdkInfraProject } from '@xpertss/projen-types';\n\nconst project = new CdkInfraProject({\n  name: 'my-infra',\n});\n\nproject.addGitIgnore('*.log');\nproject.addGitIgnore('.env.*');\nproject.addGitIgnore('/build/');\n\nproject.synth();\n```\n\nThe same works for every type - just swap the class (e.g. `JavaServiceProject`, `GitHubActionProject`). Each call takes one standard gitignore glob pattern. There is no `gitignore` constructor option: the project types' option interfaces do not expose one, so patterns go through `addGitIgnore()` instead.\n\nRe-run `npx projen` after editing - `.gitignore` is a generated file, so hand-editing it is caught by the drift check.\n\n## Troubleshooting\n\n**`Unable to find projen project. Use \"projen new\" to create a new project.`**\nIf the directory already has a `.projenrc.ts`, this error means the rc has\nnever been synthesized (there's no `.projen/tasks.json`), not that you need a\nnew project. See [Starting from an existing `.projenrc.ts`](#starting-from-an-existing-projenrcts).\n\n## Going further\n\nThe project types are composed from smaller components you can also attach to your own projects:\n\n| Component | Applies to | Purpose |\n| --- | --- | --- |\n| `AppRuntimeScaffold` | `NodeProject` | App source skeleton (`app.ts` + handlers) |\n| `DatabaseComponent` | `NodeProject` | Database construct stub + migration tool wiring |\n| `EcrEcsConstructs` | `Project` | ECR + Fargate ECS construct helper |\n| `EdgeNetworkingConstructs` | `Project` | Per-resource edge networking construct helpers |\n| `MavenPom` | `Project` | A `pom.xml` with modules, BOM imports, dependency/plugin management, and exact versions only |\n| `MavenModule` | `JavaMavenProject` | One module of a reactor (created by `addModule()`) |\n| `MavenUpgradeReport` | `GitHubProject` | Nightly report-only `upgrade.yml` |\n| `MavenCentralPublish` | `JavaMavenProject` | Manual-dispatch Maven Central publish workflow |\n| `DockerPublish` | `JavaMavenProject` | Manual-dispatch Docker build+push workflow |\n| `GitHubPackagesPublish` | `JavaMavenProject` | Manual-dispatch GitHub Packages publish workflow |\n| `FlywayMigration` | `JavaSpringBootProject` | Flyway plugin/dependency + migrations directory |\n| `CdkDeployHook` | `JavaMavenProject` | Manual-dispatch workflow that triggers `deploy.yml` in a companion CDK repo |\n| `CodeIndexWorkflow` | `JavaMavenProject` | Code index generation on push to `main` |\n| `ActionBuildWorkflow` | `GitHubProject` | The `lint` task (shellcheck/yamllint/pinned actionlint) + `build.yml` |\n| `ActionDogfoodWorkflow` | `GitHubProject` | `test-dogfood.yml` from an `ActionDogfoodOptions` scenario |\n| `SonarWorkflow` | `GitHubProject` | `sonar.yml` (SonarCloud scan via the Scanner CLI); opt-in, shared by every type via `sonarHostUrl` |\n\nExample - adding a Docker publish to a `JavaMavenProject` (`JavaServiceProject` is the packaged version of this, with Spring Boot):\n\n```typescript\nimport { DockerPublish, JavaMavenProject } from '@xpertss/projen-types';\n\nconst project = new JavaMavenProject({\n  name: 'my-service',\n  groupId: 'org.xpertss',\n  artifactId: 'my-service',\n});\n\nnew DockerPublish(project, { dockerRegistry: 'ghcr.io' });\n\nproject.synth();\n```\n\nThe full API reference, including every option and property, is in [API.md](./API.md).\n"
+    "markdown": "# @xpertss/projen-types\n\nProjen project types for CDK/TypeScript and Java/Maven projects.\n\nInstead of hand-maintaining `pom.xml`, `cdk.json`, and GitHub workflows, you declare a project type in a `.projenrc.ts` file and let [projen](https://github.com/projen/projen) generate (and keep up to date) the whole scaffold: build files, source skeletons, CI workflows, and deploy pipelines.\n\n## Project types at a glance\n\n| Type | What it is | Publishes to | Generated workflows |\n| --- | --- | --- | --- |\n| `CdkInfraProject` | Pure-infrastructure CDK stacks (CloudFront, Route53, SQS, API Gateway, Cognito, ECR/ECS for externally-built images) | - | `build` (PR checks), `deploy` (manual dispatch) |\n| `CdkAppProject` | Full TypeScript service behind API Gateway: infra + app source + database | - | `build`, `deploy`, `app-build` (PR checks) |\n| `JavaMavenProject` | Plain Maven project, single- or multi-module, no framework | - | `build`, `upgrade` (nightly report) |\n| `JavaLibraryProject` | Reusable Java library | Maven Central | `build`, `upgrade` (nightly report), `publish-maven-central`, `codeindex` |\n| `JavaAppProject` | GUI/TUI/CLI Java application | GitHub Packages | `build`, `upgrade` (nightly report), `publish-ghpackages` |\n| `JavaSpringBootProject` | Spring Boot on Maven, single- or multi-module, **no Docker** | - | `build`, `upgrade` (nightly report) |\n| `JavaServiceProject` | Spring Boot service deployed as a container | Docker Hub | `build`, `upgrade` (nightly report), `publish-docker`, `deploy-cdk` |\n| `GitHubActionProject` | Reusable GitHub Action or Workflow | GitHub Releases | `build`, `test-dogfood`, `sonar`, `release` |\n\nThe Java types are layered, so pick the lowest layer that does what you need:\n\n```text\nJavaMavenProject            java_maven         Maven only; single- or multi-module; any supported Java line\n├── JavaLibraryProject      java_library       + Maven Central publish, source/javadoc jars, code index\n├── JavaAppProject          java_app           + GitHub Packages publish\n└── JavaSpringBootProject   java_spring_boot   + Spring Boot BOM and executable-jar repackaging; no Docker/Flyway/CDK\n    └── JavaServiceProject  java_service       + Docker publish, Flyway, CDK deploy hook (single-module)\n```\n\nEvery Java type targets a configurable Java line (`javaVersion`: `1.8`, `17`, `21` or `25`; see [Java version support](#java-version-support)), and every one except `JavaServiceProject` can be a multi-module Maven reactor (see [JavaMavenProject](#javamavenproject)).\n\nOne foundation class is also exported for advanced use: `CdkTypescriptProject` (shared CDK + TypeScript base for the CDK types).\n\nAll project types:\n\n- run a **drift check** in PR builds - a job that re-runs projen and fails if generated files were hand-edited. Edit `.projenrc.ts`, then run `npx projen`; never edit generated files directly.\n- use the GitHub secret `PROJEN_GITHUB_TOKEN` (a fine-grained PAT) for projen's automation. Override with `gheTokenSecret`.\n- make all publishing/deploying **manual** (workflow_dispatch) rather than on every merge.\n- offer an opt-in SonarCloud scan (`sonar.yml`) on any type via `sonarHostUrl` (see [SonarCloud (opt-in)](#sonarcloud-opt-in)).\n\n## Getting started\n\nHow you start depends on what is already in the directory:\n\n| Starting point | Do this |\n| --- | --- |\n| Empty directory | `projen new --from` (below) |\n| Existing repo, no `.projenrc.ts` | `projen new --from ... --no-git` (below) |\n| A `.projenrc.ts` but no `.projen/` directory - copied from another repo, or one of the [examples](#examples) pasted into a fresh repo | [Starting from an existing `.projenrc.ts`](#starting-from-an-existing-projenrcts) |\n\nScaffold the repo with projen's own bootstrap, pointed at this package:\n\n```bash\nmkdir my-project && cd my-project\ngit init\nnpx projen new --from @xpertss/projen-types cdk_infra --name my-project\n```\n\nThat writes a starter `.projenrc.ts`, synthesizes the whole scaffold and\ninstalls dependencies. The type names `projen new` accepts are `cdk_infra`,\n`cdk_app`, `java_maven`, `java_library`, `java_app`, `java_spring_boot`,\n`java_service` and `git_hub_action`; pass a bogus one to have it list them.\nRequired options become flags: `--name` for every type, plus\n`--group-id`/`--artifact-id` (Java). Any other plainly-typed option can be\npassed the same way - `--sonar-host-url` (opt-in Sonar, all types),\n`--java-version 1.8`, `--cdk-deploy-target-repo owner/repo`,\n`--docker-registry ghcr.io`, `--no-use-flyway`, and so on. Modules can't be\npassed on the command line; add them to `.projenrc.ts` afterwards (see\n[JavaMavenProject](#javamavenproject)).\n\n**Adding projen to a repo that already has content.** `projen new` runs\n`git init` and commits the scaffold by default. In a repo with existing work,\npass `--no-git` so it writes the files and leaves committing to you:\n\n```bash\ncd existing-repo\nnpx projen new --from @xpertss/projen-types java_spring_boot --name obeya --group-id org.xpertss.obeya --artifact-id obeya-parent --no-git\n```\n\n**Commit a lockfile.** The generated `build.yml` and drift check install the\ntoolchain with `npm ci`, which needs a committed `package-lock.json`, and\n`projen new` doesn't always leave one behind. Run `npm install` once and\ncommit `package-lock.json` along with the scaffold. Without it those\nworkflows fail with an `::error::` that says exactly this. For the Java\ntypes, `package.json` is generated, and it pins `projen` and\n`@xpertss/projen-types` to **exact** versions (no `^`), so every machine and\nCI run uses the same generator. A floating range would make the drift check\nreport the differences between generator versions as drift.\n\nCommit the result. From then on, every change to the scaffold goes through\n`.projenrc.ts` followed by `npx projen`:\n\n```bash\nnpx projen\n```\n\nEvery type scaffolds from that one command; no option is *required* that\n`projen new` cannot pass. The structured options - `environments` and\n`GitHubActionProject`'s `dogfood` - are ones projen's CLI cannot render\ninto a projenrc, so they are added afterwards by editing `.projenrc.ts` and\nre-running `npx projen`. Leaving `environments` out simply generates no\ndeploy workflow; leaving `dogfood` out (or a service's\n`cdkDeployTargetRepo`) still generates the workflow, with one step that\nfails and tells you what to add - a gate this package considers load-bearing\nis allowed to be missing loudly, never silently.\n\nThe `name` option must match the `name` field in the project's `package.json` (for the CDK types). For the Java types it becomes the root pom's `<name>` and the generated `package.json` name.\n\n> **Never write projen's generated-file marker text literally in `.projenrc.ts`.** projen deletes, as an orphaned generated file, any file containing the marker line (`~~ Generated by projen. To modify, ...`), and that includes `.projenrc.ts` itself. When you generate a file yourself (for example with `TextFile`), insert the marker through the file's `marker` property: ``file.addLine(`# ${file.marker}`)``.\n\n## Starting from an existing `.projenrc.ts`\n\nA directory that has a `.projenrc.ts` but no `.projen/` directory has never\nbeen synthesized. This happens when you copy the rc from another repo, or paste\none of the [examples](#examples) into a fresh repo. In that state `npx projen`\nfails with:\n\n```\n👾 Unable to find projen project. Use \"projen new\" to create a new project.\n```\n\n`npx projen` doesn't run `.projenrc.ts` itself. It runs the `default` task\nlisted in `.projen/tasks.json`, and that file is written by the first synth.\nDo the first synth one of these two ways. After that, `npx projen` works as\nusual.\n\n**Option 1 (recommended): run `projen new` over the existing rc.** `projen\nnew` leaves an existing `.projenrc.ts` untouched and writes the rest of the\nscaffold, `.projen/` included. Pass the type and its required flags as you\nwould for a new repo. Their values don't have to match your rc, because the\n`npx projen` that follows re-synthesizes everything from the rc:\n\n```bash\nnpx projen new --from @xpertss/projen-types git_hub_action --name pull-request --sonar-host-url https://sonarcloud.io --no-git\nnpx projen\n```\n\nThe first command's output reflects only the flags. For example, a\n`GitHubActionProject`'s `test-dogfood.yml` is still the failing placeholder.\nThe second command applies everything in the rc (`dogfood`, `environments`,\nmodules, and so on).\n\n**Option 2 (Java types and `GitHubActionProject`): run the rc directly,\nonce.** The CDK types run their rc differently, so for those use option 1.\nInstall what the rc imports, give\nts-node a placeholder `tsconfig.projen.json` (the synth overwrites it with the\ngenerated one), and run the same command the generated `default` task runs:\n\n```bash\nnpm i -D projen @xpertss/projen-types constructs\necho '{}' > tsconfig.projen.json\nnpx -y -p ts-node@10.9.2 -p typescript@6.0.3 ts-node --project tsconfig.projen.json .projenrc.ts\nnpx projen\n```\n\nThe `echo` line works in bash and PowerShell. Don't drop `--project`: without\na tsconfig, ts-node fails on Node 22+ with `Unknown file extension \".ts\"`.\n\nEither way, commit `.projen/` along with the rest of the scaffold. A fresh\nclone then has its `tasks.json`, and `npx projen` works there straight away.\n\n## Updating an existing project when this package changes\n\nYour generated scaffold reflects the *installed* version of `@xpertss/projen-types` - `npx projen` reads your project type from the package in `node_modules`, not from this repository. So when this package ships a change (a bug fix, a new generated file, or altered workflow behavior), an existing project picks it up by bumping the dependency and re-synthesizing. A stale `node_modules` silently regenerates with the old behavior, so the bump is the load-bearing step.\n\nUsing the [`auto-commit` action](#githubactionproject) as a running example, say a new release adds the `# Purpose:` workflow header and SonarCloud wording. In the `auto-commit` repo:\n\n```bash\nnpm view @xpertss/projen-types version        # what's the newest release?\nnpm i -D @xpertss/projen-types@latest         # bump the installed project type\nnpx projen                                    # re-synthesize every generated file\ngit diff                                      # review before committing\n```\n\nThe diff here is the workflows gaining a `# Purpose:` comment and `sonar.yml` reflecting the SonarCloud wording. Commit the result with a normal `chore:` or `fix:` message - you never hand-edit the generated files themselves.\n\n## Examples\n\nEach example shows the `projen new` command first, then a fuller\n`.projenrc.ts`. Run the command first, then replace the generated\n`.projenrc.ts` with the example (or merge it in) and run `npx projen`. If you\npasted the example into a fresh repo first instead, see\n[Starting from an existing `.projenrc.ts`](#starting-from-an-existing-projenrcts).\n\n### CdkInfraProject\n\nPure infrastructure stacks with optional ECR/ECS and edge-networking constructs.\n\nScaffold it with the `cdk_infra` type:\n\n```bash\nnpx projen new --from @xpertss/projen-types cdk_infra --name media-edge-infra\n```\n\n```typescript\n// .projenrc.ts\nimport { CdkInfraProject } from '@xpertss/projen-types';\n\nconst project = new CdkInfraProject({\n  name: 'media-edge-infra',\n  environments: [\n    'dev',\n    { name: 'stage', accountId: '111111111111', region: 'eu-central-1' },\n    { name: 'prod', accountId: '222222222222', region: 'eu-central-1', requiresApproval: true },\n  ],\n  edgeResources: ['cloudfront', 'route53', 'sqs'],\n  ecrEcs: { enabled: true, externalImageSource: true },\n});\n\nproject.synth();\n```\n\nYou get:\n\n- `cdk.json`, `cdk synth` / `cdk diff` / `cdk deploy` tasks, and the standard `AwsCdkTypeScriptApp` layout (CDK 2.189.1 by default).\n- `.github/workflows/build.yml` - PR build that hard-fails on projen drift.\n- `.github/workflows/deploy.yml` - manual dispatch with one `deploy-<env>` job per environment (runs `cdk deploy --all` with `--context environment=<env>`); `requiresApproval` environments get a GitHub Environment approval gate.\n- `LICENSE` (MIT by default), `.editorconfig`, and the projen drift check.\n- `src/constructs/edge-networking.ts` - helper constructs only for the requested `edgeResources` (`cloudfront`, `route53`, `apigateway`, `cognito`, `sqs`).\n- `src/constructs/ecr-ecs.ts` when `ecrEcs.enabled` - ECR repo + Fargate service; `externalImageSource: true` (default) means the service pulls an image built outside this repo.\n\n### CdkAppProject\n\n`CdkInfraProject` plus application source, a database construct, and an app-level build workflow.\n\nScaffold it with the `cdk_app` type:\n\n```bash\nnpx projen new --from @xpertss/projen-types cdk_app --name video-api\n```\n\n```typescript\n// .projenrc.ts\nimport { CdkAppProject } from '@xpertss/projen-types';\n\nconst project = new CdkAppProject({\n  name: 'video-api',\n  environments: ['dev', 'prod'],\n  edgeResources: ['apigateway'],\n  database: { engine: 'postgres', migrationTool: 'flyway' },\n  appEntryPoint: 'src/app.ts',\n});\n\nproject.synth();\n```\n\nEverything from `CdkInfraProject`, plus:\n\n- `src/app.ts` - application entrypoint stub (`export function handler()`).\n- `src/handlers/example.ts` - API Gateway proxy handler stub, with `@types/aws-lambda` added as a dev dependency.\n- `src/constructs/database.ts` - a `Database` construct stub for the chosen engine (`postgres`/`mysql` -> RDS, `dynamodb` -> DynamoDB). `migrationTool` (no default, intentionally) is added as a dev dependency and referenced in the stub - wiring it up is left to you.\n- `.github/workflows/app-build.yml` - runs the project's test task on every PR, then checks for projen drift.\n\n### JavaMavenProject\n\nA plain Maven build with no framework and no publish target. It's the base of every other Java type, and it's usable on its own. It's single-module until you add a module, then it's a multi-module reactor.\n\nScaffold it with the `java_maven` type:\n\n```bash\nnpx projen new --from @xpertss/projen-types java_maven --name legacy-tools --group-id org.xpertss --artifact-id legacy-tools --java-version 1.8\n```\n\n**Single module:**\n\n```typescript\n// .projenrc.ts\nimport { JavaMavenProject } from '@xpertss/projen-types';\n\nconst project = new JavaMavenProject({\n  name: 'legacy-tools',\n  groupId: 'org.xpertss',\n  artifactId: 'legacy-tools',\n  javaVersion: '1.8',\n});\n\nproject.addDependency('commons-io/commons-io@2.20.0');    // exact version\nproject.addTestDependency('org.assertj/assertj-core@3.27.3');\n\nproject.synth();\n```\n\n**Multi-module:** each `addModule()` call adds a module directory with its own generated `pom.xml`. The root pom becomes the `pom`-packaged reactor parent. Everything stays one projen project, with one `.projen/`, one `.gitignore` and one `tasks.json`.\n\n```typescript\n// .projenrc.ts\nimport { JavaMavenProject } from '@xpertss/projen-types';\n\nconst project = new JavaMavenProject({\n  name: 'toolkit',\n  groupId: 'org.xpertss.toolkit',\n  artifactId: 'toolkit-parent',\n  version: '0.1.0-SNAPSHOT',\n  javaVersion: '17',\n});\n\nconst model = project.addModule({ dir: 'toolkit-model', artifactId: 'toolkit-model', description: 'Domain model' });\nconst stub = project.addModule({ dir: 'tools/stub-model', artifactId: 'toolkit-stub-model' }); // nested dirs are fine\nconst cli = project.addModule({ dir: 'toolkit-cli', artifactId: 'toolkit-cli' });\n\nstub.addModuleDependency(model);                     // sibling module: versionless\ncli.addModuleDependency(model);\ncli.addDependency('info.picocli/picocli@4.7.7');     // pinned: the version moves to the parent\ncli.addDependency('org.yaml/snakeyaml');             // versionless: managed below\nproject.addManagedDependency('org.yaml/snakeyaml@2.4');\nproject.addBom('org.testcontainers/testcontainers-bom@1.21.3');\n\nproject.synth();\n```\n\nWhat the reactor looks like:\n\n- **Root `pom.xml`:**\n  - `<packaging>pom</packaging>`, with `<modules>` in `addModule` order.\n  - `<dependencyManagement>` holds the BOM imports first (`type=pom`, `scope=import`), then every module at `${project.version}`, then every pinned version.\n  - `<pluginManagement>` holds the plugin versions, and versionless `<plugins>` are inherited by every module: compiler, surefire, failsafe, jar, and enforcer.\n  - `junit-jupiter` is a test dependency every module inherits. Its version comes from `junit-bom`, or from the Spring Boot BOM in the Spring Boot types.\n- **Module `pom.xml`:** `<parent>` with the right `relativePath` (`tools/stub-model` → `../../pom.xml`), then `artifactId`, `name`, `description`, and versionless `<dependencies>`. Nothing else, unless the module adds plugins.\n- A version given to `module.addDependency`/`addTestDependency`/`addPlugin` is moved into the parent's `<dependencyManagement>`/`<pluginManagement>`, so every module that uses an artifact gets the same version. Pinning one artifact at two different versions fails the synth.\n- The synth fails with a clear message on:\n  - two modules with the same `artifactId`\n  - two modules with the same `dir`, or one `dir` nested inside another\n  - a `dir` outside the repo\n  - a module depending on itself\n  - `packaging` set to anything but `pom` on a project with modules\n\nYou get:\n\n- the root `pom.xml` (and one per module), written by this package:\n  - **exact versions only**: a range such as `^1`, `~1.2` or `[1,2)` fails the synth\n  - the compiler level, enforcer rule and JUnit line all follow `javaVersion`\n- one Maven run per build. `npx projen build` synthesizes, then runs `mvn -B verify`: compile, unit tests (surefire), package, and `*IT` integration tests (failsafe). There is no `mvn deploy` and no `dist/`.\n- `.github/workflows/build.yml`: a PR build that installs the pinned Node toolchain (`npm ci`) and the project's JDK (`actions/setup-java`, Maven cache), then runs `npx projen build`. The Maven build itself never runs a Sonar step - SonarCloud scanning is a separate, opt-in `sonar.yml` (set `sonarHostUrl`). See [Adding CI jobs](#adding-ci-jobs-to-a-java-project) and [SonarCloud (opt-in)](#sonarcloud-opt-in).\n- `.github/workflows/upgrade.yml`: a nightly (03:00 UTC) **report** of available dependency and plugin updates in the job summary. It changes nothing, because every version comes from `.projenrc.ts`; apply an update there. Turn it off with `upgradeWorkflow: false`. The same report runs locally with `npx projen upgrade`.\n- the projen drift check, `LICENSE` (MIT by default), `.editorconfig`, and a generated `package.json` that pins the projen toolchain exactly.\n- no sample code, unless `sample: true` on a single-module project.\n\n### JavaLibraryProject\n\nA reusable Java library published to Maven Central.\n\nScaffold it with the `java_library` type:\n\n```bash\nnpx projen new --from @xpertss/projen-types java_library --name common-utils --group-id org.xpertss --artifact-id common-utils\n```\n\n```typescript\n// .projenrc.ts\nimport { JavaLibraryProject } from '@xpertss/projen-types';\n\nconst project = new JavaLibraryProject({\n  name: 'common-utils',\n  groupId: 'org.xpertss',\n  artifactId: 'common-utils',\n  version: '1.0.0',\n  sonarHostUrl: 'https://sonarcloud.io',   // opt-in: adds sonar.yml (see SonarCloud)\n  mavenCentralOidc: true,\n});\n\nproject.synth();\n```\n\nYou get everything from [`JavaMavenProject`](#javamavenproject), so modules work here too, plus:\n\n- `maven-source-plugin` and `maven-javadoc-plugin`, attaching the `-sources`/`-javadoc` jars Maven Central requires. In a multi-module library every module attaches them.\n- `.github/workflows/publish-maven-central.yml` - manual dispatch running `mvn -B deploy -P release`. With `mavenCentralOidc: true` it uses Maven Central's OIDC trusted publishing (no GPG secrets needed); otherwise it expects the secrets `MAVEN_GPG_PRIVATE_KEY`, `MAVEN_GPG_PASSPHRASE`, `MAVEN_CENTRAL_USERNAME`, `MAVEN_CENTRAL_PASSWORD`.\n- `.github/workflows/codeindex.yml` - on push to `main`, generates a Java source index under `.cai/` covering every module (disable with `publishCodeIndex: false`).\n\n### JavaSpringBootProject\n\nSpring Boot on Maven, single- or multi-module, **without** Docker, Flyway or a deploy hook. It's [`JavaMavenProject`](#javamavenproject) plus Spring Boot dependency management. Use it for a Spring Boot repo that ships something other than this package's container image, such as a multi-module control plane, or for a Boot app you deploy your own way.\n\nScaffold it with the `java_spring_boot` type:\n\n```bash\nnpx projen new --from @xpertss/projen-types java_spring_boot --name obeya --group-id org.xpertss.obeya --artifact-id obeya-parent\n```\n\n```typescript\n// .projenrc.ts\nimport { JavaSpringBootProject } from '@xpertss/projen-types';\n\nconst project = new JavaSpringBootProject({\n  name: 'obeya',\n  groupId: 'org.xpertss.obeya',\n  artifactId: 'obeya-parent',\n  version: '0.1.0-SNAPSHOT',\n  javaVersion: '21',\n  copyrightOwner: 'Xpert Software',\n});\n\n// plain jar modules: shared libraries, clients, tools\nconst model = project.addModule({ dir: 'obeya-model', artifactId: 'obeya-model' });\nconst client = project.addModule({ dir: 'obeya-api-client', artifactId: 'obeya-api-client' });\nclient.addModuleDependency(model);\n\n// a Spring Boot application module, repackaged into an executable jar\nconst server = project.addSpringBootModule({ dir: 'obeya-server', artifactId: 'obeya-server' });\nserver.addModuleDependency(model);\nserver.addDependency('org.springframework.boot/spring-boot-starter-web');      // versionless: Boot's BOM manages it\nserver.addTestDependency('org.springframework.boot/spring-boot-starter-test');\n\nproject.addBom('org.testcontainers/testcontainers-bom@1.21.3');\n\nproject.synth();\n```\n\nYou get everything from [`JavaMavenProject`](#javamavenproject), plus:\n\n- `spring-boot-dependencies` imported as the **first** BOM, so starters and every library Boot manages (JUnit included) are added without a version. `springBootVersion` sets it; the default is the newest release of the line that supports `javaVersion` (see [Java version support](#java-version-support)).\n- `spring-boot-maven-plugin`, versioned in `<pluginManagement>`:\n  - In a **single-module** project the root jar is repackaged into an executable jar.\n  - In a **multi-module** project only modules added with `addSpringBootModule()` are repackaged; `addModule()` modules stay plain jars.\n  - A repackaged module needs its `@SpringBootApplication` class before `mvn verify` passes, because `repackage` fails with `Unable to find main class` until one exists. Add a module as a plain `addModule()` while it's still empty.\n- failsafe configured to run integration tests against the compiled classes rather than the repackaged jar (as `spring-boot-starter-parent` does).\n- no starters, no Docker, no Flyway, no CDK. Add the starters you need with `addDependency`.\n\n### JavaServiceProject\n\nA Spring Boot service that publishes a Docker image and can trigger deploys in a companion CDK repo. It is [`JavaSpringBootProject`](#javaspringbootproject) plus Docker, Flyway and a deploy hook. It is **single-module**, because the Docker build, the migrations and the deploy hook all assume one deployable at the repo root; `addModule()` fails and points you to `JavaSpringBootProject`.\n\nScaffold it with the `java_service` type:\n\n```bash\nnpx projen new --from @xpertss/projen-types java_service --name stream-processor --group-id org.xpertss --artifact-id stream-processor\n```\n\n```typescript\n// .projenrc.ts\nimport { JavaServiceProject } from '@xpertss/projen-types';\n\nconst project = new JavaServiceProject({\n  name: 'stream-processor',\n  groupId: 'org.xpertss',\n  artifactId: 'stream-processor',\n  dockerRegistry: 'docker.io/xpertss',\n  cdkDeployTargetRepo: 'xpertss/stream-infra',\n  environments: ['dev', { name: 'prod', requiresApproval: true }],\n});\n\nproject.synth();\n```\n\nYou get everything from [`JavaSpringBootProject`](#javaspringbootproject) (and so from `JavaMavenProject`), plus:\n\n- `spring-boot-starter-web` added to the pom (versionless; Boot's BOM manages it).\n- `.github/workflows/publish-docker.yml` - manual dispatch: `mvn -B package && docker build -t <registry>/<name>:<sha>`, logged in with the `DOCKER_USERNAME` / `DOCKER_PASSWORD` secrets. `dockerRegistry` defaults to `docker.io`.\n- Flyway wiring when `useFlyway` (default `true`): `flyway-core` (versionless, so it matches what Boot's Flyway auto-configuration expects), `flyway-maven-plugin` pinned for the Java line, and `src/main/resources/db/migration/V1__init.sql`.\n- `.github/workflows/deploy-cdk.yml` (the `CdkDeployHook`, generated by default) - manual dispatch with an environment selector; each job sends a `workflow_dispatch` to `deploy.yml` in the companion `cdkDeployTargetRepo` (a `CdkInfraProject`/`CdkAppProject` repo). With no `cdkDeployTargetRepo` set, the workflow is still generated but each job's only step fails with instructions - it is dispatch-only, so that lands on whoever tries to deploy rather than on every PR. Turn the workflow off entirely with `cdkDeployHook: false`. `environments` defaults to `['prod']`.\n\n### JavaAppProject\n\nA GUI/TUI/CLI Java application published to GitHub Packages only - no Maven Central, no Docker, no CDK deploy hook.\n\nScaffold it with the `java_app` type:\n\n```bash\nnpx projen new --from @xpertss/projen-types java_app --name studio-cli --group-id org.xpertss --artifact-id studio-cli\n```\n\n```typescript\n// .projenrc.ts\nimport { JavaAppProject } from '@xpertss/projen-types';\n\nconst project = new JavaAppProject({\n  name: 'studio-cli',\n  groupId: 'org.xpertss',\n  artifactId: 'studio-cli',\n  ghPackagesRegistry: 'https://maven.pkg.github.com/xpertss/studio-cli',\n});\n\nproject.synth();\n```\n\nYou get everything from [`JavaMavenProject`](#javamavenproject) (modules included), plus `.github/workflows/publish-ghpackages.yml` - manual dispatch running `mvn -B deploy -DaltDeploymentRepository=github::<registry>`, authenticated with `GITHUB_TOKEN`. `ghPackagesRegistry` defaults to `https://maven.pkg.github.com/<repo>` derived from the repository URL.\n\n### GitHubActionProject\n\nA reusable GitHub Action or Workflow. This example scaffolds an action that stages a folder and, only if it changed, commits and pushes it.\n\nScaffold it with the `git_hub_action` type:\n\n```bash\nnpx projen new --from @xpertss/projen-types git_hub_action --name auto-commit --sonar-host-url https://sonarcloud.io\n```\n\n```typescript\n// .projenrc.ts\nimport { GitHubActionProject } from '@xpertss/projen-types';\n\nconst project = new GitHubActionProject({\n  name: 'auto-commit',\n  description: 'Stage a folder and, only if it changed, commit and push it',\n  sonarHostUrl: 'https://sonarcloud.io',       // optional - set it to add sonar.yml (see SonarCloud)\n  sonarOrganization: 'xpertss',                 // default - your SonarCloud org key\n  dogfood: {\n    // Two scenario steps: the \"changed\" path and the \"no-op\" path are both\n    // load-bearing behavior for this action (a double-commit or a\n    // push-when-empty bug is the failure mode a hand-rolled inline-shell\n    // alternative is most likely to introduce).\n    scenario: [\n      {\n        name: 'Changed path',\n        fixtureSteps: [\n          'echo \"$(date -u +%Y%m%dT%H%M%SZ)\" >> test/fixtures/dogfood-state.txt',\n        ],\n        inputs: {\n          commit_message: 'test: dogfood',\n          branches: 'test/dogfood',\n        },\n        assertions: [\n          // step id defaults to a slug of `name` - here \"changed-path-0\"\n          '[ \"${{ steps.changed-path-0.outputs.committed }}\" = \"true\" ]',\n        ],\n      },\n      {\n        // No fixture change this time - nothing new to commit.\n        name: 'No-op path',\n        id: 'no-op-check',            // pin an explicit id instead of relying on the default slug\n        inputs: {\n          commit_message: 'test: dogfood',\n          branches: 'test/dogfood',\n        },\n        assertions: [\n          '[ \"${{ steps.no-op-check.outputs.committed }}\" = \"false\" ]',\n        ],\n      },\n    ],\n    cleanup: [\n      'git push origin --delete test/dogfood || true',\n    ],\n  },\n});\n\nproject.synth();\n```\n\nYou get:\n\n- `action.yml` and `auto-commit.sh` are hand-written - this type only lints their content via `build.yml`'s shellcheck/yamllint/actionlint checks.\n- `.github/workflows/build.yml` - lint gate: `apt`-installed shellcheck/yamllint plus a pinned, SHA-256-verified `actionlint` release binary. Runs on `pull_request` (and `workflow_dispatch`) only - the release path runs the same lint task inside its `release` job before tagging, so push-to-`main` runs would be a duplicate (alongside `sonar.yml` when Sonar is enabled).\n- `.github/workflows/test-dogfood.yml` - runs the `dogfood.scenario` steps above against this repo's own `action.yml` (via `uses: ./`), then the shared `cleanup`, on `workflow_dispatch`, every `pull_request`, and nightly. Omit `dogfood` and the workflow still exists, with one step that fails on every PR until you declare a scenario - AD-001 allows a dogfood to be missing loudly, never silently. A *partial* `dogfood` (a scenario with no cleanup) is a synth error.\n- `.github/workflows/sonar.yml` - SonarCloud scan via the Scanner CLI (the quality gate blocks the PR), scanning `action.yml`/`.github/workflows/**`/`**/*.sh` explicitly. Opt-in: generated only when `sonarHostUrl` is set (see [SonarCloud (opt-in)](#sonarcloud-opt-in)).\n- `.github/workflows/release.yml` - `feat:`/`fix:` commits on `main` bump the version, tag `vX.Y.Z`, and create a GitHub Release.\n- `.github/workflows/projen-drift-check.yml` and `workflow-change-notice.yml` - drift detection and a change notice, always included.\n- `package.json` (**private**, version source only), `.yamllint`, `LICENSE` (MIT by default), and a `README.md` template - all regenerated by `npx projen`.\n\nNeeds `PROJEN_GITHUB_TOKEN` (used for automated PR comments), and `SONAR_TOKEN` only when Sonar is enabled (see [SonarCloud (opt-in)](#sonarcloud-opt-in)). Onboard a brand-new action repo by running the `projen new` command above first (see [Getting started](#getting-started)), then replace the generated `.projenrc.ts` with the one above and run `npx projen`, then hand-write `action.yml`/`auto-commit.sh`/`test/fixtures/`. If you wrote the `.projenrc.ts` before running `projen new`, see [Starting from an existing `.projenrc.ts`](#starting-from-an-existing-projenrcts).\n\n## Java version support\n\n`javaVersion` picks the Java line a Java project targets. It defaults to `21`; the supported lines are `1.8` (alias `8`), `17`, `21` and `25`, and any other value fails the synth with that list. **Nothing in the generated build is hard-coded to one Java line.** Everything that depends on it comes from one table in this package, grouped by line:\n\n| | `1.8` | `17` | `21` | `25` |\n| --- | --- | --- | --- | --- |\n| Compiler level | `maven.compiler.source`/`target` = `1.8` (javac 8 has no `--release`) | `maven.compiler.release` = `17` | `release` = `21` | `release` = `25` |\n| Enforcer `requireJavaVersion` | `[1.8,)` | `[17,)` | `[21,)` | `[25,)` |\n| JUnit (`junit-bom`) | 5.14.4 (JUnit 6 needs Java 17) | 6.1.3 | 6.1.3 | 6.1.3 |\n| Default Spring Boot (`JavaSpringBootProject`) | 2.7.18 (Boot 3+ needs Java 17; a 3.x+ `springBootVersion` fails the synth) | 4.1.1 | 4.1.1 | 4.1.1 |\n| `flyway-maven-plugin` (`JavaServiceProject`) | 9.22.3 | 13.9.0 | 13.9.0 | 13.9.0 |\n| CI JDK (`actions/setup-java` `java-version`) | `8` | `17` | `21` | `25` |\n\nMaven plugins (the same on every line, because all of them run on JDK 8): `maven-compiler-plugin` 3.16.0, `maven-surefire-plugin`/`maven-failsafe-plugin` 3.6.0, `maven-jar-plugin` 3.5.1, `maven-enforcer-plugin` 3.6.3, `maven-source-plugin` 3.4.0 and `maven-javadoc-plugin` 3.12.0 (library only), `versions-maven-plugin` 2.22.0 (the `upgrade` report).\n\n**The enforcer.** `maven-enforcer-plugin` fails the build at the start when the JDK or Maven running it is older than the project needs. Without it you get confusing compiler errors later, or a jar built for the wrong runtime. Its Java rule always follows `javaVersion`. The Maven rule defaults to `[3.9,)`; change it with `minMavenVersion`, or drop the plugin entirely with `enforcer: false`. CI installs the matching JDK through `setup-java`, so the rule only fires on a developer machine with the wrong JDK. A Java 1.8 project builds on any newer JDK (the rule is a minimum), but the JDK 8 runtime API is guaranteed only when you build on JDK 8.\n\n**Overriding a version.** `pluginVersions` replaces any default in the table, keyed by `groupId/artifactId`, with an exact version:\n\n```typescript\nnew JavaMavenProject({\n  name: 'svc',\n  groupId: 'org.xpertss',\n  artifactId: 'svc',\n  pluginVersions: {\n    'org.apache.maven.plugins/maven-surefire-plugin': '3.5.6',\n    'org.junit/junit-bom': '5.14.4',\n  },\n});\n```\n\n`project.pinnedVersion('org.apache.maven.plugins/maven-surefire-plugin')` returns the version in effect, for reuse in your own plugin config.\n\n**New Java lines** are one new row in this package's version table and a release. Until a line is listed, `javaVersion` rejects it rather than guessing.\n\n## Adding CI jobs to a Java project\n\n`build.yml` is exposed as `project.buildVerifyWorkflow`, so jobs are added through projen's `addJob` rather than `addOverride`. `project.ciSetupSteps` holds the steps every Maven job here needs: pinned Node, `npm ci`, and the project's JDK with a Maven cache. Every job in `build.yml` can then be made a required check on `main`.\n\n```typescript\nimport { github } from 'projen';\n\nproject.buildVerifyWorkflow.addJob('integration', {\n  name: 'Container integration tests',\n  runsOn: ['self-hosted', 'linux', 'fedora', 'podman'],\n  permissions: { contents: github.workflows.JobPermission.READ },\n  steps: [\n    { name: 'Checkout', uses: 'actions/checkout@v7' },\n    ...project.ciSetupSteps,\n    { name: 'Integration tests', run: 'mvn -B verify -Pcontainer-its' },\n  ],\n});\n```\n\n## Common options\n\nCDK project types (`CdkInfraProjectOptions` / `CdkAppProjectOptions`):\n\n| Option | Default | Description |\n| --- | --- | --- |\n| `name` | - (required) | Project name; must match `package.json` |\n| `cdkVersion` | `2.189.1` | AWS CDK version |\n| `gheTokenSecret` | `PROJEN_GITHUB_TOKEN` | GitHub secret holding projen's PAT |\n| `licensed` | `true` | Write a `LICENSE` |\n| `license` | `MIT` | SPDX identifier for the `LICENSE` |\n| `copyrightOwner` / `copyrightPeriod` | `Xpert Software` / current year | Named in the `LICENSE` |\n| `environments` | - (no `deploy` workflow) | Deploy targets for the `deploy` workflow; strings or `EnvironmentOptions` |\n| `ecrEcs` | - | `EcrEcsOptions` - `enabled`, `externalImageSource` (default `true`) |\n| `edgeResources` | - | Subset of `cloudfront`, `route53`, `apigateway`, `cognito`, `sqs` |\n| `database` | - (app only) | `DatabaseOptions` - `engine` (`postgres`/`mysql`/`dynamodb`, default `postgres`), `migrationTool` |\n| `appEntryPoint` | `src/app.ts` (app only) | Path of the generated application entrypoint |\n\nJava project types (`JavaMavenProjectOptions` and everything built on it - `JavaLibraryProjectOptions`, `JavaAppProjectOptions`, `JavaSpringBootProjectOptions`, `JavaServiceProjectOptions`):\n\n| Option | Default | Description |\n| --- | --- | --- |\n| `name` | - (required) | Project name |\n| `groupId` | - (required) | Maven group id |\n| `artifactId` | - (required) | Maven artifact id (of the reactor parent, in a multi-module project) |\n| `version` | `0.1.0` | Maven version; must be exact |\n| `description` / `url` | - | Written to the root pom |\n| `javaVersion` | `21` | Java line: `1.8`, `17`, `21`, `25` - see [Java version support](#java-version-support) |\n| `javaDistribution` | `temurin` | `actions/setup-java` distribution for CI |\n| `packaging` | `jar` | Root packaging while the project has no modules; a project with modules is always `pom` |\n| `sample` | `false` | Starter `Main` + test under the `groupId` package (single-module only) |\n| `enforcer` | `true` | `maven-enforcer-plugin` with Maven and Java version rules |\n| `minMavenVersion` | `3.9` | The enforcer's `requireMavenVersion` minimum |\n| `pluginVersions` | - | Exact-version overrides for this package's defaults, keyed by `groupId/artifactId` |\n| `licensed` | `true` | Write a `LICENSE` |\n| `license` | `MIT` | SPDX identifier for the `LICENSE` |\n| `copyrightOwner` / `copyrightPeriod` | `Xpert Software` / current year | Named in the `LICENSE` |\n| `editorconfig` | `true` | Write a projen-managed `.editorconfig` (also on the CDK and action types) |\n| `upgradeWorkflow` | `true` | Generate the nightly update report (`upgrade.yml`) |\n| Sonar options | - | `sonarHostUrl`, `sonarOrganization`, `sonarTokenSecret`, `sonarPullRequestGate`, `sonarProjectKey` - SonarCloud is opt-in; see [SonarCloud (opt-in)](#sonarcloud-opt-in) |\n| `gheTokenSecret` | `PROJEN_GITHUB_TOKEN` | GitHub secret holding projen's PAT |\n| `springBootVersion` | newest Boot for `javaVersion` (Spring Boot types only) | Exact Spring Boot version: the BOM and `spring-boot-maven-plugin` |\n| `cdkDeployTargetRepo` | - (service only; `deploy-cdk.yml` fails until set) | Companion CDK repo (`owner/repo`) whose `deploy.yml` the deploy hook dispatches |\n| `cdkDeployHook` | `true` (service only) | Whether to generate `deploy-cdk.yml` at all |\n| `dockerRegistry` | `docker.io` (service only) | Registry the Docker image is pushed to |\n| `useFlyway` | `true` (service only) | Flyway plugin/dependency + `V1__init.sql` |\n\nWith the default MIT license, the generated `LICENSE` looks like:\n\n```\nMIT License\n\nCopyright (c) 2024-2026 Xpert Software\n\nPermission is hereby granted, ...\n```\n\nThe header line (`MIT License`) is specific to the license type — an `Apache-2.0` project would instead show `Apache-2.0`.\n\nOverride the license type and copyright fields:\n\n```typescript\nnew JavaMavenProject({\n  name: 'my-lib',\n  groupId: 'org.xpertss',\n  artifactId: 'my-lib',\n  license: 'Apache-2.0',            // any SPDX id projen ships a template for\n  copyrightOwner: 'Xpert Software',\n  copyrightPeriod: '2024-2026',\n});\n```\n\n`EnvironmentOptions` for deploy targets:\n\n```text\ninterface EnvironmentOptions {\n  readonly name: string;              // e.g. \"dev\", \"stage\", \"prod\"\n  readonly accountId?: string;        // AWS account id (CDK deploys)\n  readonly region?: string;           // AWS region (CDK deploys)\n  readonly requiresApproval?: boolean; // GitHub Environment approval gate (default false)\n}\n```\n\nPlain strings (`'dev'`) are shorthand for `{ name: 'dev' }`.\n\n`GitHubActionProjectOptions`:\n\n| Option | Default | Description |\n| --- | --- | --- |\n| `name` | - (required) | Project name |\n| `description` | - | One-line description; used in the default README template and recorded in the private `package.json` |\n| Sonar options | - | `sonarHostUrl`, `sonarOrganization`, `sonarTokenSecret`, `sonarPullRequestGate`, `sonarProjectKey` - SonarCloud is opt-in; see [SonarCloud (opt-in)](#sonarcloud-opt-in) |\n| `dogfood` | - (a `test-dogfood.yml` that fails until you declare one) | `ActionDogfoodOptions` - the scenario that exercises the action end-to-end via `uses: ./` |\n| `license` | `MIT` | SPDX identifier for the generated `LICENSE` |\n| `copyrightOwner` / `copyrightPeriod` | `Xpert Software` / current year | Named in the `LICENSE` |\n| `gheTokenSecret` | `PROJEN_GITHUB_TOKEN` | GitHub secret holding projen's PAT (drift-check PR comments); a dogfood that passes a `token` input must reference this secret in the step's `inputs` |\n\n`ActionDogfoodOptions`/`ActionDogfoodStep` - the dogfood scenario (`test-dogfood.yml`):\n\n```text\ninterface ActionDogfoodOptions {\n  readonly scenario: ActionDogfoodStep[]; // one or more, run in order - required\n  readonly cleanup: string[];             // shared, run once at the end with `if: always()` - required\n}\n\ninterface ActionDogfoodStep {\n  readonly name: string;                    // labels this step-group's generated workflow steps\n  readonly id?: string;                     // step id for the `uses: ./` call; default: a slug of `name`\n  readonly fixtureSteps?: string[];         // shell, before the invocation (default: none)\n  readonly inputs?: Record<string, string>; // `with:` for this invocation (default: none)\n   readonly assertions: string[];            // shell, after the invocation - required; the step runs under set -euo pipefail so any failing line fails the job\n}\n```\n\nMost actions need exactly one `scenario` step. Actions with a re-run/no-op/idempotency behavior to verify (e.g. `auto-commit`'s no-op-on-no-change path, `create-pull-request`'s reuse-the-PR path) declare two - the second typically omits `fixtureSteps` so its invocation sees no new state, and its assertion checks the opposite outcome of the first. Reference an invocation's own outputs from a later assertion via `${{ steps.<id>.outputs.<name> }}`, using either the default slug or an explicit `id`.\n\n## SonarCloud (opt-in)\n\nSonarCloud is a shared, **opt-in** capability on every project type (CDK, Java, and GitHub Action). Set `sonarHostUrl` on any type and it generates a `.github/workflows/sonar.yml` that runs a pinned, SHA-256-verified Sonar Scanner CLI and blocks the PR on the quality gate. Omit it and no `sonar.yml` is generated. The Maven build itself never runs a Sonar step.\n\nShared options (accepted by the CDK types, every Java type, and `GitHubActionProject`):\n\n| Option | Default | Description |\n| --- | --- | --- |\n| `sonarHostUrl` | - (required to enable) | URL of your SonarCloud instance (e.g. `https://sonarcloud.io`); must be reachable from github.com-hosted runners |\n| `sonarOrganization` | `xpertss` | SonarCloud org key (`sonar.organization`); required by the Scanner CLI, not derived from the token |\n| `sonarProjectKey` | `${sonarOrganization}_${name}` | `sonar.projectKey` - the org + project key SonarCloud uses (e.g. `xpertss_create-pull-request`) |\n| `sonarTokenSecret` | `SONAR_TOKEN` | GitHub secret holding the Sonar token |\n| `sonarPullRequestGate` | `true` | Whether `sonar.yml` also runs on `pull_request` as a pass/fail gate |\n\nInclusions differ by type: a `GitHubActionProject` scans `action.yml`/`.github/workflows/**`/`**/*.sh` explicitly (YAML and shell are not in Sonar's default-recognized set), while the CDK and Java types rely on Sonar's default inclusions for their languages.\n\n```typescript\nnew CdkInfraProject({\n  name: 'my-infra',\n  environments: ['dev', 'prod'],\n  sonarHostUrl: 'https://sonarcloud.io',   // adds sonar.yml\n});\n```\n\nRequires the `SONAR_TOKEN` secret (rename it with `sonarTokenSecret`).\n\n## Required GitHub secrets\n\n| Secret | Used by | Notes |\n| --- | --- | --- |\n| `PROJEN_GITHUB_TOKEN` | all types | PAT for projen's self-mutation/automation; override via `gheTokenSecret` |\n| `SONAR_TOKEN` | any type with `sonarHostUrl` set | SonarCloud scan in `sonar.yml`; override the secret name via `sonarTokenSecret` |\n| `DOCKER_USERNAME` / `DOCKER_PASSWORD` | `JavaServiceProject` | Docker image push |\n| `MAVEN_GPG_PRIVATE_KEY`, `MAVEN_GPG_PASSPHRASE`, `MAVEN_CENTRAL_USERNAME`, `MAVEN_CENTRAL_PASSWORD` | `JavaLibraryProject` without `mavenCentralOidc` | Not needed with OIDC trusted publishing |\n\n## Customizing `.gitignore`\n\nEvery project type already ignores JetBrains IDE state (`/.idea/*`) and the `/spec/` directory with all of its subdirectories (local plans and specs, never committed). The Java types also ignore Maven `target/` output and Eclipse files. To ignore more, call the inherited `addGitIgnore()` method after constructing the project in your `.projenrc.ts`:\n\n```typescript\n// .projenrc.ts\nimport { CdkInfraProject } from '@xpertss/projen-types';\n\nconst project = new CdkInfraProject({\n  name: 'my-infra',\n});\n\nproject.addGitIgnore('*.log');\nproject.addGitIgnore('.env.*');\nproject.addGitIgnore('/build/');\n\nproject.synth();\n```\n\nThe same works for every type - just swap the class (e.g. `JavaServiceProject`, `GitHubActionProject`). Each call takes one standard gitignore glob pattern. There is no `gitignore` constructor option: the project types' option interfaces do not expose one, so patterns go through `addGitIgnore()` instead.\n\nRe-run `npx projen` after editing - `.gitignore` is a generated file, so hand-editing it is caught by the drift check.\n\n## Troubleshooting\n\n**`Unable to find projen project. Use \"projen new\" to create a new project.`**\nIf the directory already has a `.projenrc.ts`, this error means the rc has\nnever been synthesized (there's no `.projen/tasks.json`), not that you need a\nnew project. See [Starting from an existing `.projenrc.ts`](#starting-from-an-existing-projenrcts).\n\n## Going further\n\nThe project types are composed from smaller components you can also attach to your own projects:\n\n| Component | Applies to | Purpose |\n| --- | --- | --- |\n| `AppRuntimeScaffold` | `NodeProject` | App source skeleton (`app.ts` + handlers) |\n| `DatabaseComponent` | `NodeProject` | Database construct stub + migration tool wiring |\n| `EcrEcsConstructs` | `Project` | ECR + Fargate ECS construct helper |\n| `EdgeNetworkingConstructs` | `Project` | Per-resource edge networking construct helpers |\n| `MavenPom` | `Project` | A `pom.xml` with modules, BOM imports, dependency/plugin management, and exact versions only |\n| `MavenModule` | `JavaMavenProject` | One module of a reactor (created by `addModule()`) |\n| `MavenUpgradeReport` | `GitHubProject` | Nightly report-only `upgrade.yml` |\n| `MavenCentralPublish` | `JavaMavenProject` | Manual-dispatch Maven Central publish workflow |\n| `DockerPublish` | `JavaMavenProject` | Manual-dispatch Docker build+push workflow |\n| `GitHubPackagesPublish` | `JavaMavenProject` | Manual-dispatch GitHub Packages publish workflow |\n| `FlywayMigration` | `JavaSpringBootProject` | Flyway plugin/dependency + migrations directory |\n| `CdkDeployHook` | `JavaMavenProject` | Manual-dispatch workflow that triggers `deploy.yml` in a companion CDK repo |\n| `CodeIndexWorkflow` | `JavaMavenProject` | Code index generation on push to `main` |\n| `ActionBuildWorkflow` | `GitHubProject` | The `lint` task (shellcheck/yamllint/pinned actionlint) + `build.yml` |\n| `ActionDogfoodWorkflow` | `GitHubProject` | `test-dogfood.yml` from an `ActionDogfoodOptions` scenario |\n| `SonarWorkflow` | `GitHubProject` | `sonar.yml` (SonarCloud scan via the Scanner CLI); opt-in, shared by every type via `sonarHostUrl` |\n\nExample - adding a Docker publish to a `JavaMavenProject` (`JavaServiceProject` is the packaged version of this, with Spring Boot):\n\n```typescript\nimport { DockerPublish, JavaMavenProject } from '@xpertss/projen-types';\n\nconst project = new JavaMavenProject({\n  name: 'my-service',\n  groupId: 'org.xpertss',\n  artifactId: 'my-service',\n});\n\nnew DockerPublish(project, { dockerRegistry: 'ghcr.io' });\n\nproject.synth();\n```\n\nThe full API reference, including every option and property, is in [API.md](./API.md).\n"
   },
   "repository": {
     "type": "git",
@@ -123,7 +123,7 @@
       "assembly": "@xpertss/projen-types",
       "base": "projen.Component",
       "docs": {
-        "remarks": "Creates a dedicated `lint` task\n(named to avoid colliding with projen's own reserved `build` task, which\nspawns the unrelated default/pre-compile/compile/post-compile/test/package\nchain - including `default`, i.e. re-running `.projenrc.ts`, which is not\nwhat this gate is for) and wraps it in a `TaskWorkflow` (`build.yml`)\ntriggered on push-to-`main` and `pull_request`. The same task is reused by\nthe release build job, so the lint commands exist in exactly one place.",
+        "remarks": "Creates a dedicated `lint` task\n(named to avoid colliding with projen's own reserved `build` task, which\nspawns the unrelated default/pre-compile/compile/post-compile/test/package\nchain - including `default`, i.e. re-running `.projenrc.ts`, which is not\nwhat this gate is for) and wraps it in a `TaskWorkflow` (`build.yml`)\ntriggered on `pull_request` (plus `TaskWorkflow`'s automatic\n`workflow_dispatch`). `push: main` is deliberately not a trigger: the\nrelease path already runs this same `lint` task inside the `release` job\n(the `tasks` wiring in `GitHubActionProject`), before the tag and GitHub\nRelease are created - so a push-to-`main` run here would execute the lint\ntwice in parallel and gate nothing, because the release job never waits on\n`build.yml`. The lint commands exist in exactly one place: the `lint`\ntask.",
         "stability": "experimental",
         "summary": "The AD-001 Layer-1 lint gate for a composite-action repo: shellcheck, yamllint, and a pinned `actionlint` release binary (verified by SHA-256, never a marketplace action - org policy)."
       },
@@ -134,7 +134,7 @@
         },
         "locationInModule": {
           "filename": "src/actions/action-build-workflow.ts",
-          "line": 25
+          "line": 31
         },
         "parameters": [
           {
@@ -148,7 +148,7 @@
       "kind": "class",
       "locationInModule": {
         "filename": "src/actions/action-build-workflow.ts",
-        "line": 21
+        "line": 27
       },
       "name": "ActionBuildWorkflow",
       "properties": [
@@ -159,7 +159,7 @@
           "immutable": true,
           "locationInModule": {
             "filename": "src/actions/action-build-workflow.ts",
-            "line": 22
+            "line": 28
           },
           "name": "task",
           "type": {
@@ -173,7 +173,7 @@
           "immutable": true,
           "locationInModule": {
             "filename": "src/actions/action-build-workflow.ts",
-            "line": 23
+            "line": 29
           },
           "name": "workflow",
           "type": {
@@ -4766,6 +4766,6 @@
       "symbolId": "src/common/workflow-change-notice-workflow:WorkflowChangeNoticeWorkflowOptions"
     }
   },
-  "version": "0.0.25",
-  "fingerprint": "7Ix+lwCPpv4KsX8SQrBj4ac/B/mgdhDncrPcU7a10LU="
+  "version": "0.0.26",
+  "fingerprint": "2UcPfhqA/4BeG4UomwdroNTe6pS6xgb2vd86e+p0dEU="
 }

package/API.md

@@ -11,8 +11,14 @@ Creates a dedicated `lint` task
 spawns the unrelated default/pre-compile/compile/post-compile/test/package
 chain - including `default`, i.e. re-running `.projenrc.ts`, which is not
 what this gate is for) and wraps it in a `TaskWorkflow` (`build.yml`)
-triggered on push-to-`main` and `pull_request`. The same task is reused by
-the release build job, so the lint commands exist in exactly one place.
+triggered on `pull_request` (plus `TaskWorkflow`'s automatic
+`workflow_dispatch`). `push: main` is deliberately not a trigger: the
+release path already runs this same `lint` task inside the `release` job
+(the `tasks` wiring in `GitHubActionProject`), before the tag and GitHub
+Release are created - so a push-to-`main` run here would execute the lint
+twice in parallel and gate nothing, because the release job never waits on
+`build.yml`. The lint commands exist in exactly one place: the `lint`
+task.
 
 #### Initializers <a name="Initializers" id="@xpertss/projen-types.ActionBuildWorkflow.Initializer"></a>
 

package/README.md

@@ -539,7 +539,7 @@ project.synth();
 You get:
 
 - `action.yml` and `auto-commit.sh` are hand-written - this type only lints their content via `build.yml`'s shellcheck/yamllint/actionlint checks.
-- `.github/workflows/build.yml` - lint gate: `apt`-installed shellcheck/yamllint plus a pinned, SHA-256-verified `actionlint` release binary. Gates `main` (alongside `sonar.yml` when Sonar is enabled).
+- `.github/workflows/build.yml` - lint gate: `apt`-installed shellcheck/yamllint plus a pinned, SHA-256-verified `actionlint` release binary. Runs on `pull_request` (and `workflow_dispatch`) only - the release path runs the same lint task inside its `release` job before tagging, so push-to-`main` runs would be a duplicate (alongside `sonar.yml` when Sonar is enabled).
 - `.github/workflows/test-dogfood.yml` - runs the `dogfood.scenario` steps above against this repo's own `action.yml` (via `uses: ./`), then the shared `cleanup`, on `workflow_dispatch`, every `pull_request`, and nightly. Omit `dogfood` and the workflow still exists, with one step that fails on every PR until you declare a scenario - AD-001 allows a dogfood to be missing loudly, never silently. A *partial* `dogfood` (a scenario with no cleanup) is a synth error.
 - `.github/workflows/sonar.yml` - SonarCloud scan via the Scanner CLI (the quality gate blocks the PR), scanning `action.yml`/`.github/workflows/**`/`**/*.sh` explicitly. Opt-in: generated only when `sonarHostUrl` is set (see [SonarCloud (opt-in)](#sonarcloud-opt-in)).
 - `.github/workflows/release.yml` - `feat:`/`fix:` commits on `main` bump the version, tag `vX.Y.Z`, and create a GitHub Release.

package/lib/actions/action-build-workflow.d.ts

@@ -7,8 +7,14 @@ import { Component, Task, github } from 'projen';
  * spawns the unrelated default/pre-compile/compile/post-compile/test/package
  * chain - including `default`, i.e. re-running `.projenrc.ts`, which is not
  * what this gate is for) and wraps it in a `TaskWorkflow` (`build.yml`)
- * triggered on push-to-`main` and `pull_request`. The same task is reused by
- * the release build job, so the lint commands exist in exactly one place.
+ * triggered on `pull_request` (plus `TaskWorkflow`'s automatic
+ * `workflow_dispatch`). `push: main` is deliberately not a trigger: the
+ * release path already runs this same `lint` task inside the `release` job
+ * (the `tasks` wiring in `GitHubActionProject`), before the tag and GitHub
+ * Release are created - so a push-to-`main` run here would execute the lint
+ * twice in parallel and gate nothing, because the release job never waits on
+ * `build.yml`. The lint commands exist in exactly one place: the `lint`
+ * task.
  */
 export declare class ActionBuildWorkflow extends Component {
     readonly task: Task;

package/lib/actions/action-build-workflow.js

@@ -16,11 +16,17 @@ const ACTIONLINT_SHA256 = '8aca8db96f1b94770f1b0d72b6dddcb1ebb8123cb3712530b08cc
  * spawns the unrelated default/pre-compile/compile/post-compile/test/package
  * chain - including `default`, i.e. re-running `.projenrc.ts`, which is not
  * what this gate is for) and wraps it in a `TaskWorkflow` (`build.yml`)
- * triggered on push-to-`main` and `pull_request`. The same task is reused by
- * the release build job, so the lint commands exist in exactly one place.
+ * triggered on `pull_request` (plus `TaskWorkflow`'s automatic
+ * `workflow_dispatch`). `push: main` is deliberately not a trigger: the
+ * release path already runs this same `lint` task inside the `release` job
+ * (the `tasks` wiring in `GitHubActionProject`), before the tag and GitHub
+ * Release are created - so a push-to-`main` run here would execute the lint
+ * twice in parallel and gate nothing, because the release job never waits on
+ * `build.yml`. The lint commands exist in exactly one place: the `lint`
+ * task.
  */
 class ActionBuildWorkflow extends projen_1.Component {
-    static [JSII_RTTI_SYMBOL_1] = { fqn: "@xpertss/projen-types.ActionBuildWorkflow", version: "0.0.25" };
+    static [JSII_RTTI_SYMBOL_1] = { fqn: "@xpertss/projen-types.ActionBuildWorkflow", version: "0.0.26" };
     task;
     workflow;
     constructor(scope) {
@@ -56,7 +62,7 @@ class ActionBuildWorkflow extends projen_1.Component {
             name: 'build',
             jobId: 'build',
             task: this.task,
-            triggers: { push: { branches: ['main'] }, pullRequest: {} },
+            triggers: { pullRequest: {} },
             permissions: { contents: projen_1.github.workflows.JobPermission.READ },
             preBuildSteps: [{ name: 'Install dependencies', run: 'npm ci' }],
         });
@@ -64,4 +70,4 @@ class ActionBuildWorkflow extends projen_1.Component {
     }
 }
 exports.ActionBuildWorkflow = ActionBuildWorkflow;
-//# sourceMappingURL=data:application/json;base64,eyJ2ZXJzaW9uIjozLCJmaWxlIjoiYWN0aW9uLWJ1aWxkLXdvcmtmbG93LmpzIiwic291cmNlUm9vdCI6IiIsInNvdXJjZXMiOlsiLi4vLi4vc3JjL2FjdGlvbnMvYWN0aW9uLWJ1aWxkLXdvcmtmbG93LnRzIl0sIm5hbWVzIjpbXSwibWFwcGluZ3MiOiI7Ozs7QUFBQSxtQ0FBaUQ7QUFDakQsaUVBQWlFO0FBRWpFLDBFQUEwRTtBQUMxRSw0REFBNEQ7QUFDNUQsTUFBTSxrQkFBa0IsR0FBRyxRQUFRLENBQUM7QUFDcEMsTUFBTSxpQkFBaUIsR0FDckIsa0VBQWtFLENBQUM7QUFFckU7Ozs7Ozs7Ozs7R0FVRztBQUNILE1BQWEsbUJBQW9CLFNBQVEsa0JBQVM7O0lBQ2hDLElBQUksQ0FBTztJQUNYLFFBQVEsQ0FBc0I7SUFFOUMsWUFBWSxLQUEyQjtRQUNyQyxLQUFLLENBQUMsS0FBSyxFQUFFLHFCQUFxQixDQUFDLENBQUM7UUFFcEMsTUFBTSxFQUFFLEdBQUcsS0FBSyxDQUFDLE1BQU0sQ0FBQztRQUN4QixJQUFJLENBQUMsRUFBRSxFQUFFLENBQUM7WUFDUixNQUFNLElBQUksS0FBSyxDQUNiLCtEQUErRCxDQUNoRSxDQUFDO1FBQ0osQ0FBQztRQUVELElBQUksQ0FBQyxJQUFJLEdBQUcsS0FBSyxDQUFDLE9BQU8sQ0FBQyxNQUFNLEVBQUU7WUFDaEMsV0FBVyxFQUFFLG9EQUFvRDtTQUNsRSxDQUFDLENBQUM7UUFDSCxJQUFJLENBQUMsSUFBSSxDQUFDLElBQUksQ0FDWix1RUFBdUUsQ0FDeEUsQ0FBQztRQUNGLElBQUksQ0FBQyxJQUFJLENBQUMsSUFBSSxDQUNaLHFGQUFxRixDQUN0RixDQUFDO1FBQ0Ysa0VBQWtFO1FBQ2xFLGlFQUFpRTtRQUNqRSxJQUFJLENBQUMsSUFBSSxDQUFDLElBQUksQ0FBQyxrQ0FBa0MsQ0FBQyxDQUFDO1FBQ25ELHlFQUF5RTtRQUN6RSx3RUFBd0U7UUFDeEUsNkNBQTZDO1FBQzdDLHVFQUF1RTtRQUN2RSw4REFBOEQ7UUFDOUQsd0VBQXdFO1FBQ3hFLHdFQUF3RTtRQUN4RSxzRUFBc0U7UUFDdEUsSUFBSSxDQUFDLElBQUksQ0FBQyxJQUFJLENBQ1o7WUFDRSxvQkFBb0I7WUFDcEIsa0dBQWtHLGtCQUFrQixlQUFlLGtCQUFrQixzQkFBc0I7WUFDM0ssU0FBUyxpQkFBaUIsNENBQTRDO1lBQ3RFLHdEQUF3RDtZQUN4RCx3REFBd0Q7U0FDekQsQ0FBQyxJQUFJLENBQUMsTUFBTSxDQUFDLENBQ2YsQ0FBQztRQUVGLElBQUksQ0FBQyxRQUFRLEdBQUcsSUFBSSxlQUFNLENBQUMsWUFBWSxDQUFDLEVBQUUsRUFBRTtZQUMxQyxJQUFJLEVBQUUsT0FBTztZQUNiLEtBQUssRUFBRSxPQUFPO1lBQ2QsSUFBSSxFQUFFLElBQUksQ0FBQyxJQUFJO1lBQ2YsUUFBUSxFQUFFLEVBQUUsSUFBSSxFQUFFLEVBQUUsUUFBUSxFQUFFLENBQUMsTUFBTSxDQUFDLEVBQUUsRUFBRSxXQUFXLEVBQUUsRUFBRSxFQUFFO1lBQzNELFdBQVcsRUFBRSxFQUFFLFFBQVEsRUFBRSxlQUFNLENBQUMsU0FBUyxDQUFDLGFBQWEsQ0FBQyxJQUFJLEVBQUU7WUFDOUQsYUFBYSxFQUFFLENBQUMsRUFBRSxJQUFJLEVBQUUsc0JBQXNCLEVBQUUsR0FBRyxFQUFFLFFBQVEsRUFBRSxDQUFDO1NBQ2pFLENBQUMsQ0FBQztRQUNILElBQUEsc0NBQW1CLEVBQ2pCLElBQUksQ0FBQyxRQUFRLENBQUMsSUFBSSxFQUNsQiw4REFBOEQsQ0FDL0QsQ0FBQztJQUNKLENBQUM7O0FBeERILGtEQXlEQyIsInNvdXJjZXNDb250ZW50IjpbImltcG9ydCB7IENvbXBvbmVudCwgVGFzaywgZ2l0aHViIH0gZnJvbSAncHJvamVuJztcbmltcG9ydCB7IG5vdGVXb3JrZmxvd1B1cnBvc2UgfSBmcm9tICcuLi9jb21tb24vd29ya2Zsb3ctcHVycG9zZSc7XG5cbi8vIFBpbm5lZCByZWxlYXNlICsgdmVyaWZpZWQgU0hBLTI1NiAobGludXhfYW1kNjQpIC0gdXBncmFkZSBpcyBhIHJldmlld2VkXG4vLyBkaWZmIG9mIHRoaXMgY29uc3RhbnQsIG5ldmVyIGEgZmxvYXRpbmcgdmVyc2lvbiAoQUQtMDAxKS5cbmNvbnN0IEFDVElPTkxJTlRfVkVSU0lPTiA9ICcxLjcuMTInO1xuY29uc3QgQUNUSU9OTElOVF9TSEEyNTYgPVxuICAnOGFjYThkYjk2ZjFiOTQ3NzBmMWIwZDcyYjZkZGRjYjFlYmI4MTIzY2IzNzEyNTMwYjA4Y2MzODdiMzQ5YTNkOCc7XG5cbi8qKlxuICogVGhlIEFELTAwMSBMYXllci0xIGxpbnQgZ2F0ZSBmb3IgYSBjb21wb3NpdGUtYWN0aW9uIHJlcG86IHNoZWxsY2hlY2ssXG4gKiB5YW1sbGludCwgYW5kIGEgcGlubmVkIGBhY3Rpb25saW50YCByZWxlYXNlIGJpbmFyeSAodmVyaWZpZWQgYnkgU0hBLTI1NixcbiAqIG5ldmVyIGEgbWFya2V0cGxhY2UgYWN0aW9uIC0gb3JnIHBvbGljeSkuIENyZWF0ZXMgYSBkZWRpY2F0ZWQgYGxpbnRgIHRhc2tcbiAqIChuYW1lZCB0byBhdm9pZCBjb2xsaWRpbmcgd2l0aCBwcm9qZW4ncyBvd24gcmVzZXJ2ZWQgYGJ1aWxkYCB0YXNrLCB3aGljaFxuICogc3Bhd25zIHRoZSB1bnJlbGF0ZWQgZGVmYXVsdC9wcmUtY29tcGlsZS9jb21waWxlL3Bvc3QtY29tcGlsZS90ZXN0L3BhY2thZ2VcbiAqIGNoYWluIC0gaW5jbHVkaW5nIGBkZWZhdWx0YCwgaS5lLiByZS1ydW5uaW5nIGAucHJvamVucmMudHNgLCB3aGljaCBpcyBub3RcbiAqIHdoYXQgdGhpcyBnYXRlIGlzIGZvcikgYW5kIHdyYXBzIGl0IGluIGEgYFRhc2tXb3JrZmxvd2AgKGBidWlsZC55bWxgKVxuICogdHJpZ2dlcmVkIG9uIHB1c2gtdG8tYG1haW5gIGFuZCBgcHVsbF9yZXF1ZXN0YC4gVGhlIHNhbWUgdGFzayBpcyByZXVzZWQgYnlcbiAqIHRoZSByZWxlYXNlIGJ1aWxkIGpvYiwgc28gdGhlIGxpbnQgY29tbWFuZHMgZXhpc3QgaW4gZXhhY3RseSBvbmUgcGxhY2UuXG4gKi9cbmV4cG9ydCBjbGFzcyBBY3Rpb25CdWlsZFdvcmtmbG93IGV4dGVuZHMgQ29tcG9uZW50IHtcbiAgcHVibGljIHJlYWRvbmx5IHRhc2s6IFRhc2s7XG4gIHB1YmxpYyByZWFkb25seSB3b3JrZmxvdzogZ2l0aHViLlRhc2tXb3JrZmxvdztcblxuICBjb25zdHJ1Y3RvcihzY29wZTogZ2l0aHViLkdpdEh1YlByb2plY3QpIHtcbiAgICBzdXBlcihzY29wZSwgJ0FjdGlvbkJ1aWxkV29ya2Zsb3cnKTtcblxuICAgIGNvbnN0IGdoID0gc2NvcGUuZ2l0aHViO1xuICAgIGlmICghZ2gpIHtcbiAgICAgIHRocm93IG5ldyBFcnJvcihcbiAgICAgICAgJ0FjdGlvbkJ1aWxkV29ya2Zsb3cgcmVxdWlyZXMgR2l0SHViIGludGVncmF0aW9uIHRvIGJlIGVuYWJsZWQnLFxuICAgICAgKTtcbiAgICB9XG5cbiAgICB0aGlzLnRhc2sgPSBzY29wZS5hZGRUYXNrKCdsaW50Jywge1xuICAgICAgZGVzY3JpcHRpb246ICdMaW50IHRoZSBhY3Rpb24gKHNoZWxsY2hlY2ssIHlhbWxsaW50LCBhY3Rpb25saW50KScsXG4gICAgfSk7XG4gICAgdGhpcy50YXNrLmV4ZWMoXG4gICAgICAnc3VkbyBhcHQtZ2V0IHVwZGF0ZSAteSAmJiBzdWRvIGFwdC1nZXQgaW5zdGFsbCAteSBzaGVsbGNoZWNrIHlhbWxsaW50JyxcbiAgICApO1xuICAgIHRoaXMudGFzay5leGVjKFxuICAgICAgJ2ZpbmQgLiAtcGF0aCAuL25vZGVfbW9kdWxlcyAtcHJ1bmUgLW8gLW5hbWUgXCIqLnNoXCIgLXByaW50MCB8IHhhcmdzIC0wIC1yIHNoZWxsY2hlY2snLFxuICAgICk7XG4gICAgLy8gSGFuZC13cml0dGVuIFlBTUwgb25seTogdGhlIHdvcmtmbG93cyBhcmUgcHJvamVuLWdlbmVyYXRlZCAoYW5kXG4gICAgLy8gZHJpZnQtY2hlY2tlZCksIGFuZCB0aGVpciBsb25nIGxpbmVzIHdvdWxkIGZhaWwgYGxpbmUtbGVuZ3RoYC5cbiAgICB0aGlzLnRhc2suZXhlYygneWFtbGxpbnQgLWMgLnlhbWxsaW50IGFjdGlvbi55bWwnKTtcbiAgICAvLyBPbmUgc3RlcCwgc28gdGhlIHByaXZhdGUgYG1rdGVtcCAtZGAgZGlyIGNhcnJpZXMgZnJvbSBkb3dubG9hZCB0aHJvdWdoXG4gICAgLy8gZXhlY3V0aW9uIC0gbmV2ZXIgdGhlIHdvcmxkLXdyaXRhYmxlIHNoYXJlZCAvdG1wLCB3aGVyZSBhbm90aGVyIGxvY2FsXG4gICAgLy8gdXNlciBjb3VsZCBwbGFudCB0aGUgYmluYXJ5IHRoYXQgZ2V0cyBydW4uXG4gICAgLy8gV29ya2Zsb3dzIG9ubHk6IGFjdGlvbmxpbnQgcGFyc2VzIGV2ZXJ5IGZpbGUgYXJndW1lbnQgYXMgYSB3b3JrZmxvdyxcbiAgICAvLyBzbyB0aGUgY29tcG9zaXRlIGBhY3Rpb24ueW1sYCBpcyB2YWxpZGF0ZWQgdHJhbnNpdGl2ZWx5IHZpYVxuICAgIC8vIGB1c2VzOiAuL2AgaW5zdGVhZC4gYC1zaGVsbGNoZWNrPWAgZGlzYWJsZXMgaXRzIGluY2lkZW50YWwgc2hlbGxjaGVja1xuICAgIC8vIHBhc3Mgb3ZlciBnZW5lcmF0ZWQgYHJ1bjpgIHNjcmlwdHMgKGUuZy4gcHJvamVuJ3Mgb3duIGByZWxlYXNlLnltbGApO1xuICAgIC8vIGhhbmQtd3JpdHRlbiBgKi5zaGAgZmlsZXMgYXJlIGNvdmVyZWQgYnkgdGhlIHNoZWxsY2hlY2sgc3RlcCBhYm92ZS5cbiAgICB0aGlzLnRhc2suZXhlYyhcbiAgICAgIFtcbiAgICAgICAgJ1RNUD1cIiQobWt0ZW1wIC1kKVwiJyxcbiAgICAgICAgYGN1cmwgLWZzU0wgLW8gXCIkVE1QL2FjdGlvbmxpbnQudGFyLmd6XCIgXCJodHRwczovL2dpdGh1Yi5jb20vcmh5c2QvYWN0aW9ubGludC9yZWxlYXNlcy9kb3dubG9hZC92JHtBQ1RJT05MSU5UX1ZFUlNJT059L2FjdGlvbmxpbnRfJHtBQ1RJT05MSU5UX1ZFUlNJT059X2xpbnV4X2FtZDY0LnRhci5nelwiYCxcbiAgICAgICAgYGVjaG8gXCIke0FDVElPTkxJTlRfU0hBMjU2fSAgJFRNUC9hY3Rpb25saW50LnRhci5nelwiIHwgc2hhMjU2c3VtIC1jIC1gLFxuICAgICAgICAndGFyIC14emYgXCIkVE1QL2FjdGlvbmxpbnQudGFyLmd6XCIgLUMgXCIkVE1QXCIgYWN0aW9ubGludCcsXG4gICAgICAgICdcIiRUTVAvYWN0aW9ubGludFwiIC1zaGVsbGNoZWNrPSAuZ2l0aHViL3dvcmtmbG93cy8qLnltbCcsXG4gICAgICBdLmpvaW4oJyAmJiAnKSxcbiAgICApO1xuXG4gICAgdGhpcy53b3JrZmxvdyA9IG5ldyBnaXRodWIuVGFza1dvcmtmbG93KGdoLCB7XG4gICAgICBuYW1lOiAnYnVpbGQnLFxuICAgICAgam9iSWQ6ICdidWlsZCcsXG4gICAgICB0YXNrOiB0aGlzLnRhc2ssXG4gICAgICB0cmlnZ2VyczogeyBwdXNoOiB7IGJyYW5jaGVzOiBbJ21haW4nXSB9LCBwdWxsUmVxdWVzdDoge30gfSxcbiAgICAgIHBlcm1pc3Npb25zOiB7IGNvbnRlbnRzOiBnaXRodWIud29ya2Zsb3dzLkpvYlBlcm1pc3Npb24uUkVBRCB9LFxuICAgICAgcHJlQnVpbGRTdGVwczogW3sgbmFtZTogJ0luc3RhbGwgZGVwZW5kZW5jaWVzJywgcnVuOiAnbnBtIGNpJyB9XSxcbiAgICB9KTtcbiAgICBub3RlV29ya2Zsb3dQdXJwb3NlKFxuICAgICAgdGhpcy53b3JrZmxvdy5maWxlLFxuICAgICAgJ0xpbnQgZ2F0ZSBmb3IgdGhlIGFjdGlvbiAoc2hlbGxjaGVjaywgeWFtbGxpbnQsIGFjdGlvbmxpbnQpLicsXG4gICAgKTtcbiAgfVxufVxuIl19
+//# sourceMappingURL=data:application/json;base64,eyJ2ZXJzaW9uIjozLCJmaWxlIjoiYWN0aW9uLWJ1aWxkLXdvcmtmbG93LmpzIiwic291cmNlUm9vdCI6IiIsInNvdXJjZXMiOlsiLi4vLi4vc3JjL2FjdGlvbnMvYWN0aW9uLWJ1aWxkLXdvcmtmbG93LnRzIl0sIm5hbWVzIjpbXSwibWFwcGluZ3MiOiI7Ozs7QUFBQSxtQ0FBaUQ7QUFDakQsaUVBQWlFO0FBRWpFLDBFQUEwRTtBQUMxRSw0REFBNEQ7QUFDNUQsTUFBTSxrQkFBa0IsR0FBRyxRQUFRLENBQUM7QUFDcEMsTUFBTSxpQkFBaUIsR0FDckIsa0VBQWtFLENBQUM7QUFFckU7Ozs7Ozs7Ozs7Ozs7Ozs7R0FnQkc7QUFDSCxNQUFhLG1CQUFvQixTQUFRLGtCQUFTOztJQUNoQyxJQUFJLENBQU87SUFDWCxRQUFRLENBQXNCO0lBRTlDLFlBQVksS0FBMkI7UUFDckMsS0FBSyxDQUFDLEtBQUssRUFBRSxxQkFBcUIsQ0FBQyxDQUFDO1FBRXBDLE1BQU0sRUFBRSxHQUFHLEtBQUssQ0FBQyxNQUFNLENBQUM7UUFDeEIsSUFBSSxDQUFDLEVBQUUsRUFBRSxDQUFDO1lBQ1IsTUFBTSxJQUFJLEtBQUssQ0FDYiwrREFBK0QsQ0FDaEUsQ0FBQztRQUNKLENBQUM7UUFFRCxJQUFJLENBQUMsSUFBSSxHQUFHLEtBQUssQ0FBQyxPQUFPLENBQUMsTUFBTSxFQUFFO1lBQ2hDLFdBQVcsRUFBRSxvREFBb0Q7U0FDbEUsQ0FBQyxDQUFDO1FBQ0gsSUFBSSxDQUFDLElBQUksQ0FBQyxJQUFJLENBQ1osdUVBQXVFLENBQ3hFLENBQUM7UUFDRixJQUFJLENBQUMsSUFBSSxDQUFDLElBQUksQ0FDWixxRkFBcUYsQ0FDdEYsQ0FBQztRQUNGLGtFQUFrRTtRQUNsRSxpRUFBaUU7UUFDakUsSUFBSSxDQUFDLElBQUksQ0FBQyxJQUFJLENBQUMsa0NBQWtDLENBQUMsQ0FBQztRQUNuRCx5RUFBeUU7UUFDekUsd0VBQXdFO1FBQ3hFLDZDQUE2QztRQUM3Qyx1RUFBdUU7UUFDdkUsOERBQThEO1FBQzlELHdFQUF3RTtRQUN4RSx3RUFBd0U7UUFDeEUsc0VBQXNFO1FBQ3RFLElBQUksQ0FBQyxJQUFJLENBQUMsSUFBSSxDQUNaO1lBQ0Usb0JBQW9CO1lBQ3BCLGtHQUFrRyxrQkFBa0IsZUFBZSxrQkFBa0Isc0JBQXNCO1lBQzNLLFNBQVMsaUJBQWlCLDRDQUE0QztZQUN0RSx3REFBd0Q7WUFDeEQsd0RBQXdEO1NBQ3pELENBQUMsSUFBSSxDQUFDLE1BQU0sQ0FBQyxDQUNmLENBQUM7UUFFRixJQUFJLENBQUMsUUFBUSxHQUFHLElBQUksZUFBTSxDQUFDLFlBQVksQ0FBQyxFQUFFLEVBQUU7WUFDMUMsSUFBSSxFQUFFLE9BQU87WUFDYixLQUFLLEVBQUUsT0FBTztZQUNkLElBQUksRUFBRSxJQUFJLENBQUMsSUFBSTtZQUNmLFFBQVEsRUFBRSxFQUFFLFdBQVcsRUFBRSxFQUFFLEVBQUU7WUFDN0IsV0FBVyxFQUFFLEVBQUUsUUFBUSxFQUFFLGVBQU0sQ0FBQyxTQUFTLENBQUMsYUFBYSxDQUFDLElBQUksRUFBRTtZQUM5RCxhQUFhLEVBQUUsQ0FBQyxFQUFFLElBQUksRUFBRSxzQkFBc0IsRUFBRSxHQUFHLEVBQUUsUUFBUSxFQUFFLENBQUM7U0FDakUsQ0FBQyxDQUFDO1FBQ0gsSUFBQSxzQ0FBbUIsRUFDakIsSUFBSSxDQUFDLFFBQVEsQ0FBQyxJQUFJLEVBQ2xCLDhEQUE4RCxDQUMvRCxDQUFDO0lBQ0osQ0FBQzs7QUF4REgsa0RBeURDIiwic291cmNlc0NvbnRlbnQiOlsiaW1wb3J0IHsgQ29tcG9uZW50LCBUYXNrLCBnaXRodWIgfSBmcm9tICdwcm9qZW4nO1xuaW1wb3J0IHsgbm90ZVdvcmtmbG93UHVycG9zZSB9IGZyb20gJy4uL2NvbW1vbi93b3JrZmxvdy1wdXJwb3NlJztcblxuLy8gUGlubmVkIHJlbGVhc2UgKyB2ZXJpZmllZCBTSEEtMjU2IChsaW51eF9hbWQ2NCkgLSB1cGdyYWRlIGlzIGEgcmV2aWV3ZWRcbi8vIGRpZmYgb2YgdGhpcyBjb25zdGFudCwgbmV2ZXIgYSBmbG9hdGluZyB2ZXJzaW9uIChBRC0wMDEpLlxuY29uc3QgQUNUSU9OTElOVF9WRVJTSU9OID0gJzEuNy4xMic7XG5jb25zdCBBQ1RJT05MSU5UX1NIQTI1NiA9XG4gICc4YWNhOGRiOTZmMWI5NDc3MGYxYjBkNzJiNmRkZGNiMWViYjgxMjNjYjM3MTI1MzBiMDhjYzM4N2IzNDlhM2Q4JztcblxuLyoqXG4gKiBUaGUgQUQtMDAxIExheWVyLTEgbGludCBnYXRlIGZvciBhIGNvbXBvc2l0ZS1hY3Rpb24gcmVwbzogc2hlbGxjaGVjayxcbiAqIHlhbWxsaW50LCBhbmQgYSBwaW5uZWQgYGFjdGlvbmxpbnRgIHJlbGVhc2UgYmluYXJ5ICh2ZXJpZmllZCBieSBTSEEtMjU2LFxuICogbmV2ZXIgYSBtYXJrZXRwbGFjZSBhY3Rpb24gLSBvcmcgcG9saWN5KS4gQ3JlYXRlcyBhIGRlZGljYXRlZCBgbGludGAgdGFza1xuICogKG5hbWVkIHRvIGF2b2lkIGNvbGxpZGluZyB3aXRoIHByb2plbidzIG93biByZXNlcnZlZCBgYnVpbGRgIHRhc2ssIHdoaWNoXG4gKiBzcGF3bnMgdGhlIHVucmVsYXRlZCBkZWZhdWx0L3ByZS1jb21waWxlL2NvbXBpbGUvcG9zdC1jb21waWxlL3Rlc3QvcGFja2FnZVxuICogY2hhaW4gLSBpbmNsdWRpbmcgYGRlZmF1bHRgLCBpLmUuIHJlLXJ1bm5pbmcgYC5wcm9qZW5yYy50c2AsIHdoaWNoIGlzIG5vdFxuICogd2hhdCB0aGlzIGdhdGUgaXMgZm9yKSBhbmQgd3JhcHMgaXQgaW4gYSBgVGFza1dvcmtmbG93YCAoYGJ1aWxkLnltbGApXG4gKiB0cmlnZ2VyZWQgb24gYHB1bGxfcmVxdWVzdGAgKHBsdXMgYFRhc2tXb3JrZmxvd2AncyBhdXRvbWF0aWNcbiAqIGB3b3JrZmxvd19kaXNwYXRjaGApLiBgcHVzaDogbWFpbmAgaXMgZGVsaWJlcmF0ZWx5IG5vdCBhIHRyaWdnZXI6IHRoZVxuICogcmVsZWFzZSBwYXRoIGFscmVhZHkgcnVucyB0aGlzIHNhbWUgYGxpbnRgIHRhc2sgaW5zaWRlIHRoZSBgcmVsZWFzZWAgam9iXG4gKiAodGhlIGB0YXNrc2Agd2lyaW5nIGluIGBHaXRIdWJBY3Rpb25Qcm9qZWN0YCksIGJlZm9yZSB0aGUgdGFnIGFuZCBHaXRIdWJcbiAqIFJlbGVhc2UgYXJlIGNyZWF0ZWQgLSBzbyBhIHB1c2gtdG8tYG1haW5gIHJ1biBoZXJlIHdvdWxkIGV4ZWN1dGUgdGhlIGxpbnRcbiAqIHR3aWNlIGluIHBhcmFsbGVsIGFuZCBnYXRlIG5vdGhpbmcsIGJlY2F1c2UgdGhlIHJlbGVhc2Ugam9iIG5ldmVyIHdhaXRzIG9uXG4gKiBgYnVpbGQueW1sYC4gVGhlIGxpbnQgY29tbWFuZHMgZXhpc3QgaW4gZXhhY3RseSBvbmUgcGxhY2U6IHRoZSBgbGludGBcbiAqIHRhc2suXG4gKi9cbmV4cG9ydCBjbGFzcyBBY3Rpb25CdWlsZFdvcmtmbG93IGV4dGVuZHMgQ29tcG9uZW50IHtcbiAgcHVibGljIHJlYWRvbmx5IHRhc2s6IFRhc2s7XG4gIHB1YmxpYyByZWFkb25seSB3b3JrZmxvdzogZ2l0aHViLlRhc2tXb3JrZmxvdztcblxuICBjb25zdHJ1Y3RvcihzY29wZTogZ2l0aHViLkdpdEh1YlByb2plY3QpIHtcbiAgICBzdXBlcihzY29wZSwgJ0FjdGlvbkJ1aWxkV29ya2Zsb3cnKTtcblxuICAgIGNvbnN0IGdoID0gc2NvcGUuZ2l0aHViO1xuICAgIGlmICghZ2gpIHtcbiAgICAgIHRocm93IG5ldyBFcnJvcihcbiAgICAgICAgJ0FjdGlvbkJ1aWxkV29ya2Zsb3cgcmVxdWlyZXMgR2l0SHViIGludGVncmF0aW9uIHRvIGJlIGVuYWJsZWQnLFxuICAgICAgKTtcbiAgICB9XG5cbiAgICB0aGlzLnRhc2sgPSBzY29wZS5hZGRUYXNrKCdsaW50Jywge1xuICAgICAgZGVzY3JpcHRpb246ICdMaW50IHRoZSBhY3Rpb24gKHNoZWxsY2hlY2ssIHlhbWxsaW50LCBhY3Rpb25saW50KScsXG4gICAgfSk7XG4gICAgdGhpcy50YXNrLmV4ZWMoXG4gICAgICAnc3VkbyBhcHQtZ2V0IHVwZGF0ZSAteSAmJiBzdWRvIGFwdC1nZXQgaW5zdGFsbCAteSBzaGVsbGNoZWNrIHlhbWxsaW50JyxcbiAgICApO1xuICAgIHRoaXMudGFzay5leGVjKFxuICAgICAgJ2ZpbmQgLiAtcGF0aCAuL25vZGVfbW9kdWxlcyAtcHJ1bmUgLW8gLW5hbWUgXCIqLnNoXCIgLXByaW50MCB8IHhhcmdzIC0wIC1yIHNoZWxsY2hlY2snLFxuICAgICk7XG4gICAgLy8gSGFuZC13cml0dGVuIFlBTUwgb25seTogdGhlIHdvcmtmbG93cyBhcmUgcHJvamVuLWdlbmVyYXRlZCAoYW5kXG4gICAgLy8gZHJpZnQtY2hlY2tlZCksIGFuZCB0aGVpciBsb25nIGxpbmVzIHdvdWxkIGZhaWwgYGxpbmUtbGVuZ3RoYC5cbiAgICB0aGlzLnRhc2suZXhlYygneWFtbGxpbnQgLWMgLnlhbWxsaW50IGFjdGlvbi55bWwnKTtcbiAgICAvLyBPbmUgc3RlcCwgc28gdGhlIHByaXZhdGUgYG1rdGVtcCAtZGAgZGlyIGNhcnJpZXMgZnJvbSBkb3dubG9hZCB0aHJvdWdoXG4gICAgLy8gZXhlY3V0aW9uIC0gbmV2ZXIgdGhlIHdvcmxkLXdyaXRhYmxlIHNoYXJlZCAvdG1wLCB3aGVyZSBhbm90aGVyIGxvY2FsXG4gICAgLy8gdXNlciBjb3VsZCBwbGFudCB0aGUgYmluYXJ5IHRoYXQgZ2V0cyBydW4uXG4gICAgLy8gV29ya2Zsb3dzIG9ubHk6IGFjdGlvbmxpbnQgcGFyc2VzIGV2ZXJ5IGZpbGUgYXJndW1lbnQgYXMgYSB3b3JrZmxvdyxcbiAgICAvLyBzbyB0aGUgY29tcG9zaXRlIGBhY3Rpb24ueW1sYCBpcyB2YWxpZGF0ZWQgdHJhbnNpdGl2ZWx5IHZpYVxuICAgIC8vIGB1c2VzOiAuL2AgaW5zdGVhZC4gYC1zaGVsbGNoZWNrPWAgZGlzYWJsZXMgaXRzIGluY2lkZW50YWwgc2hlbGxjaGVja1xuICAgIC8vIHBhc3Mgb3ZlciBnZW5lcmF0ZWQgYHJ1bjpgIHNjcmlwdHMgKGUuZy4gcHJvamVuJ3Mgb3duIGByZWxlYXNlLnltbGApO1xuICAgIC8vIGhhbmQtd3JpdHRlbiBgKi5zaGAgZmlsZXMgYXJlIGNvdmVyZWQgYnkgdGhlIHNoZWxsY2hlY2sgc3RlcCBhYm92ZS5cbiAgICB0aGlzLnRhc2suZXhlYyhcbiAgICAgIFtcbiAgICAgICAgJ1RNUD1cIiQobWt0ZW1wIC1kKVwiJyxcbiAgICAgICAgYGN1cmwgLWZzU0wgLW8gXCIkVE1QL2FjdGlvbmxpbnQudGFyLmd6XCIgXCJodHRwczovL2dpdGh1Yi5jb20vcmh5c2QvYWN0aW9ubGludC9yZWxlYXNlcy9kb3dubG9hZC92JHtBQ1RJT05MSU5UX1ZFUlNJT059L2FjdGlvbmxpbnRfJHtBQ1RJT05MSU5UX1ZFUlNJT059X2xpbnV4X2FtZDY0LnRhci5nelwiYCxcbiAgICAgICAgYGVjaG8gXCIke0FDVElPTkxJTlRfU0hBMjU2fSAgJFRNUC9hY3Rpb25saW50LnRhci5nelwiIHwgc2hhMjU2c3VtIC1jIC1gLFxuICAgICAgICAndGFyIC14emYgXCIkVE1QL2FjdGlvbmxpbnQudGFyLmd6XCIgLUMgXCIkVE1QXCIgYWN0aW9ubGludCcsXG4gICAgICAgICdcIiRUTVAvYWN0aW9ubGludFwiIC1zaGVsbGNoZWNrPSAuZ2l0aHViL3dvcmtmbG93cy8qLnltbCcsXG4gICAgICBdLmpvaW4oJyAmJiAnKSxcbiAgICApO1xuXG4gICAgdGhpcy53b3JrZmxvdyA9IG5ldyBnaXRodWIuVGFza1dvcmtmbG93KGdoLCB7XG4gICAgICBuYW1lOiAnYnVpbGQnLFxuICAgICAgam9iSWQ6ICdidWlsZCcsXG4gICAgICB0YXNrOiB0aGlzLnRhc2ssXG4gICAgICB0cmlnZ2VyczogeyBwdWxsUmVxdWVzdDoge30gfSxcbiAgICAgIHBlcm1pc3Npb25zOiB7IGNvbnRlbnRzOiBnaXRodWIud29ya2Zsb3dzLkpvYlBlcm1pc3Npb24uUkVBRCB9LFxuICAgICAgcHJlQnVpbGRTdGVwczogW3sgbmFtZTogJ0luc3RhbGwgZGVwZW5kZW5jaWVzJywgcnVuOiAnbnBtIGNpJyB9XSxcbiAgICB9KTtcbiAgICBub3RlV29ya2Zsb3dQdXJwb3NlKFxuICAgICAgdGhpcy53b3JrZmxvdy5maWxlLFxuICAgICAgJ0xpbnQgZ2F0ZSBmb3IgdGhlIGFjdGlvbiAoc2hlbGxjaGVjaywgeWFtbGxpbnQsIGFjdGlvbmxpbnQpLicsXG4gICAgKTtcbiAgfVxufVxuIl19

package/lib/actions/action-dogfood-workflow.js

@@ -41,7 +41,7 @@ const UNCONFIGURED_STEPS = [
  * error: if you wrote a scenario by hand, you can write its cleanup too.
  */
 class ActionDogfoodWorkflow extends projen_1.Component {
-    static [JSII_RTTI_SYMBOL_1] = { fqn: "@xpertss/projen-types.ActionDogfoodWorkflow", version: "0.0.25" };
+    static [JSII_RTTI_SYMBOL_1] = { fqn: "@xpertss/projen-types.ActionDogfoodWorkflow", version: "0.0.26" };
     workflow;
     constructor(scope, options) {
         super(scope, 'ActionDogfoodWorkflow');

package/lib/actions/action-sonar-workflow.js

@@ -10,7 +10,7 @@ const sonar_workflow_1 = require("../common/sonar-workflow");
  * compiling. It behaves identically to `SonarWorkflow`.
  */
 class ActionSonarWorkflow extends sonar_workflow_1.SonarWorkflow {
-    static [JSII_RTTI_SYMBOL_1] = { fqn: "@xpertss/projen-types.ActionSonarWorkflow", version: "0.0.25" };
+    static [JSII_RTTI_SYMBOL_1] = { fqn: "@xpertss/projen-types.ActionSonarWorkflow", version: "0.0.26" };
     constructor(scope, options) {
         super(scope, options);
     }

package/lib/actions/github-action-project.js

@@ -64,7 +64,7 @@ hand-committed.
  * per the action's own F### spec - this type only lints it.
  */
 class GitHubActionProject extends projen_1.github.GitHubProject {
-    static [JSII_RTTI_SYMBOL_1] = { fqn: "@xpertss/projen-types.GitHubActionProject", version: "0.0.25" };
+    static [JSII_RTTI_SYMBOL_1] = { fqn: "@xpertss/projen-types.GitHubActionProject", version: "0.0.26" };
     buildWorkflow;
     dogfoodWorkflow;
     /** Set only when `sonarHostUrl` is provided. */

package/lib/cdk/app-runtime-scaffold.js

@@ -8,7 +8,7 @@ const projen_1 = require("projen");
  * layered on top of `CdkTypescriptProject`'s pure-infra scaffold.
  */
 class AppRuntimeScaffold extends projen_1.Component {
-    static [JSII_RTTI_SYMBOL_1] = { fqn: "@xpertss/projen-types.AppRuntimeScaffold", version: "0.0.25" };
+    static [JSII_RTTI_SYMBOL_1] = { fqn: "@xpertss/projen-types.AppRuntimeScaffold", version: "0.0.26" };
     constructor(project, appEntryPoint = 'src/app.ts') {
         super(project, 'AppRuntimeScaffold');
         const app = new projen_1.SourceCode(project, appEntryPoint);

package/lib/cdk/cdk-app-project.js

@@ -13,7 +13,7 @@ const workflow_purpose_1 = require("../common/workflow-purpose");
  * application source, a database, and an app-level build/test workflow.
  */
 class CdkAppProject extends cdk_infra_project_1.CdkInfraProject {
-    static [JSII_RTTI_SYMBOL_1] = { fqn: "@xpertss/projen-types.CdkAppProject", version: "0.0.25" };
+    static [JSII_RTTI_SYMBOL_1] = { fqn: "@xpertss/projen-types.CdkAppProject", version: "0.0.26" };
     constructor(options) {
         super(options);
         new app_runtime_scaffold_1.AppRuntimeScaffold(this, options.appEntryPoint ?? 'src/app.ts');

package/lib/cdk/cdk-infra-project.js

@@ -11,7 +11,7 @@ const edge_networking_constructs_1 = require("./components/edge-networking-const
  * externally-built images). Reference example: SimulcastAVDelivery.
  */
 class CdkInfraProject extends cdk_typescript_base_1.CdkTypescriptProject {
-    static [JSII_RTTI_SYMBOL_1] = { fqn: "@xpertss/projen-types.CdkInfraProject", version: "0.0.25" };
+    static [JSII_RTTI_SYMBOL_1] = { fqn: "@xpertss/projen-types.CdkInfraProject", version: "0.0.26" };
     constructor(options) {
         super(options);
         if (options.ecrEcs?.enabled) {

package/lib/cdk/cdk-typescript-base.js

@@ -25,7 +25,7 @@ const PROJEN_TYPES_VERSION = require('../../package.json').version;
  * `ManualDeployWorkflow` when `environments` is provided.
  */
 class CdkTypescriptProject extends projen_1.awscdk.AwsCdkTypeScriptApp {
-    static [JSII_RTTI_SYMBOL_1] = { fqn: "@xpertss/projen-types.CdkTypescriptProject", version: "0.0.25" };
+    static [JSII_RTTI_SYMBOL_1] = { fqn: "@xpertss/projen-types.CdkTypescriptProject", version: "0.0.26" };
     /** Set only when `sonarHostUrl` is provided. */
     sonarWorkflow;
     constructor(options) {

package/lib/cdk/components/ecr-ecs-constructs.js

@@ -10,7 +10,7 @@ const projen_1 = require("projen");
  * built from this project's own source (app projects).
  */
 class EcrEcsConstructs extends projen_1.Component {
-    static [JSII_RTTI_SYMBOL_1] = { fqn: "@xpertss/projen-types.EcrEcsConstructs", version: "0.0.25" };
+    static [JSII_RTTI_SYMBOL_1] = { fqn: "@xpertss/projen-types.EcrEcsConstructs", version: "0.0.26" };
     constructor(project, options = {}) {
         super(project, 'EcrEcsConstructs');
         const externalImageSource = options.externalImageSource ?? true;

package/lib/cdk/components/edge-networking-constructs.js

@@ -42,7 +42,7 @@ const HELPERS = {
  * to whichever `edgeResources` the consuming project type opts into.
  */
 class EdgeNetworkingConstructs extends projen_1.Component {
-    static [JSII_RTTI_SYMBOL_1] = { fqn: "@xpertss/projen-types.EdgeNetworkingConstructs", version: "0.0.25" };
+    static [JSII_RTTI_SYMBOL_1] = { fqn: "@xpertss/projen-types.EdgeNetworkingConstructs", version: "0.0.26" };
     constructor(project, resources) {
         super(project, 'EdgeNetworkingConstructs');
         if (resources.length === 0) {

package/lib/cdk/database-component.js

@@ -10,7 +10,7 @@ const projen_1 = require("projen");
  * the consuming team to wire up; no opinionated default is imposed.
  */
 class DatabaseComponent extends projen_1.Component {
-    static [JSII_RTTI_SYMBOL_1] = { fqn: "@xpertss/projen-types.DatabaseComponent", version: "0.0.25" };
+    static [JSII_RTTI_SYMBOL_1] = { fqn: "@xpertss/projen-types.DatabaseComponent", version: "0.0.26" };
     constructor(project, options = {}) {
         super(project, 'DatabaseComponent');
         const engine = options.engine ?? 'postgres';

package/lib/common/projen-drift-check-workflow.js

@@ -6,7 +6,7 @@ const projen_1 = require("projen");
 const ci_steps_1 = require("./ci-steps");
 const workflow_purpose_1 = require("./workflow-purpose");
 class ProjenDriftCheckWorkflow extends projen_1.Component {
-    static [JSII_RTTI_SYMBOL_1] = { fqn: "@xpertss/projen-types.ProjenDriftCheckWorkflow", version: "0.0.25" };
+    static [JSII_RTTI_SYMBOL_1] = { fqn: "@xpertss/projen-types.ProjenDriftCheckWorkflow", version: "0.0.26" };
     workflow;
     constructor(scope, options = {}) {
         super(scope, 'ProjenDriftCheckWorkflow');

package/lib/common/sonar-workflow.js

@@ -17,7 +17,7 @@ const SONAR_SCANNER_SHA256 = 'bb8f709f9cb73352f8d1260a3b3c506c0f41146754bc630762
  * enough for default-recognized languages.
  */
 class SonarWorkflow extends projen_1.Component {
-    static [JSII_RTTI_SYMBOL_1] = { fqn: "@xpertss/projen-types.SonarWorkflow", version: "0.0.25" };
+    static [JSII_RTTI_SYMBOL_1] = { fqn: "@xpertss/projen-types.SonarWorkflow", version: "0.0.26" };
     workflow;
     constructor(scope, options) {
         super(scope, 'SonarWorkflow');

package/lib/common/workflow-change-notice-workflow.js

@@ -5,7 +5,7 @@ const JSII_RTTI_SYMBOL_1 = Symbol.for("jsii.rtti");
 const projen_1 = require("projen");
 const workflow_purpose_1 = require("./workflow-purpose");
 class WorkflowChangeNoticeWorkflow extends projen_1.Component {
-    static [JSII_RTTI_SYMBOL_1] = { fqn: "@xpertss/projen-types.WorkflowChangeNoticeWorkflow", version: "0.0.25" };
+    static [JSII_RTTI_SYMBOL_1] = { fqn: "@xpertss/projen-types.WorkflowChangeNoticeWorkflow", version: "0.0.26" };
     workflow;
     constructor(scope, options = {}) {
         super(scope, 'WorkflowChangeNoticeWorkflow');

package/lib/java/components/cdk-deploy-hook.js

@@ -18,7 +18,7 @@ const manual_deploy_workflow_1 = require("../../common/manual-deploy-workflow");
  * which is exactly when "this repo has no deploy target" needs saying.
  */
 class CdkDeployHook extends projen_1.Component {
-    static [JSII_RTTI_SYMBOL_1] = { fqn: "@xpertss/projen-types.CdkDeployHook", version: "0.0.25" };
+    static [JSII_RTTI_SYMBOL_1] = { fqn: "@xpertss/projen-types.CdkDeployHook", version: "0.0.26" };
     constructor(project, environments, options = {}) {
         super(project, 'CdkDeployHook');
         const targetRepo = options.targetRepo;

package/lib/java/components/code-index-workflow.js

@@ -6,7 +6,7 @@ const projen_1 = require("projen");
 const workflow_purpose_1 = require("../../common/workflow-purpose");
 /** Generates a code index and publishes it to `.cai/` on checkin. */
 class CodeIndexWorkflow extends projen_1.Component {
-    static [JSII_RTTI_SYMBOL_1] = { fqn: "@xpertss/projen-types.CodeIndexWorkflow", version: "0.0.25" };
+    static [JSII_RTTI_SYMBOL_1] = { fqn: "@xpertss/projen-types.CodeIndexWorkflow", version: "0.0.26" };
     constructor(project) {
         super(project, 'CodeIndexWorkflow');
         const gh = project.github;

package/lib/java/components/docker-publish.js

@@ -6,7 +6,7 @@ const projen_1 = require("projen");
 const workflow_purpose_1 = require("../../common/workflow-purpose");
 /** On-demand build+push of a Docker image, defaulting to Docker Hub. */
 class DockerPublish extends projen_1.Component {
-    static [JSII_RTTI_SYMBOL_1] = { fqn: "@xpertss/projen-types.DockerPublish", version: "0.0.25" };
+    static [JSII_RTTI_SYMBOL_1] = { fqn: "@xpertss/projen-types.DockerPublish", version: "0.0.26" };
     constructor(project, options = {}) {
         super(project, 'DockerPublish');
         const gh = project.github;

package/lib/java/components/flyway-migration.js

@@ -11,7 +11,7 @@ const java_versions_1 = require("../java-versions");
  * plugin (which Boot's BOM does not manage) is pinned for the Java line.
  */
 class FlywayMigration extends projen_1.Component {
-    static [JSII_RTTI_SYMBOL_1] = { fqn: "@xpertss/projen-types.FlywayMigration", version: "0.0.25" };
+    static [JSII_RTTI_SYMBOL_1] = { fqn: "@xpertss/projen-types.FlywayMigration", version: "0.0.26" };
     constructor(project) {
         super(project, 'FlywayMigration');
         project.addPlugin(`${java_versions_1.FLYWAY_MAVEN_PLUGIN}@${project.pinnedVersion(java_versions_1.FLYWAY_MAVEN_PLUGIN)}`);

package/lib/java/components/github-packages-publish.js

@@ -6,7 +6,7 @@ const projen_1 = require("projen");
 const workflow_purpose_1 = require("../../common/workflow-purpose");
 /** On-demand publish to GitHub Packages. */
 class GitHubPackagesPublish extends projen_1.Component {
-    static [JSII_RTTI_SYMBOL_1] = { fqn: "@xpertss/projen-types.GitHubPackagesPublish", version: "0.0.25" };
+    static [JSII_RTTI_SYMBOL_1] = { fqn: "@xpertss/projen-types.GitHubPackagesPublish", version: "0.0.26" };
     constructor(project, options = {}) {
         super(project, 'GitHubPackagesPublish');
         const gh = project.github;

package/lib/java/components/maven-central-publish.js

@@ -9,7 +9,7 @@ const workflow_purpose_1 = require("../../common/workflow-purpose");
  * or OIDC trusted publishing.
  */
 class MavenCentralPublish extends projen_1.Component {
-    static [JSII_RTTI_SYMBOL_1] = { fqn: "@xpertss/projen-types.MavenCentralPublish", version: "0.0.25" };
+    static [JSII_RTTI_SYMBOL_1] = { fqn: "@xpertss/projen-types.MavenCentralPublish", version: "0.0.26" };
     constructor(project, options = {}) {
         super(project, 'MavenCentralPublish');
         const gh = project.github;

package/lib/java/components/maven-upgrade-report.js

@@ -17,7 +17,7 @@ const workflow_purpose_1 = require("../../common/workflow-purpose");
  * check. Apply an update by changing the version in `.projenrc.ts`.
  */
 class MavenUpgradeReport extends projen_1.Component {
-    static [JSII_RTTI_SYMBOL_1] = { fqn: "@xpertss/projen-types.MavenUpgradeReport", version: "0.0.25" };
+    static [JSII_RTTI_SYMBOL_1] = { fqn: "@xpertss/projen-types.MavenUpgradeReport", version: "0.0.26" };
     workflow;
     constructor(scope, options) {
         super(scope, 'MavenUpgradeReport');

package/lib/java/java-app-project.js

@@ -9,7 +9,7 @@ const java_maven_base_1 = require("./java-maven-base");
  * explicitly excludes Maven Central, Docker, and CDK deploy hooks.
  */
 class JavaAppProject extends java_maven_base_1.JavaMavenProject {
-    static [JSII_RTTI_SYMBOL_1] = { fqn: "@xpertss/projen-types.JavaAppProject", version: "0.0.25" };
+    static [JSII_RTTI_SYMBOL_1] = { fqn: "@xpertss/projen-types.JavaAppProject", version: "0.0.26" };
     constructor(options) {
         super(options);
         new github_packages_publish_1.GitHubPackagesPublish(this, {

package/lib/java/java-library-project.js

@@ -12,7 +12,7 @@ const java_versions_1 = require("./java-versions");
  * reactor, every module inherits them).
  */
 class JavaLibraryProject extends java_maven_base_1.JavaMavenProject {
-    static [JSII_RTTI_SYMBOL_1] = { fqn: "@xpertss/projen-types.JavaLibraryProject", version: "0.0.25" };
+    static [JSII_RTTI_SYMBOL_1] = { fqn: "@xpertss/projen-types.JavaLibraryProject", version: "0.0.26" };
     constructor(options) {
         super(options);
         this.addPlugin(`${java_versions_1.MAVEN_SOURCE_PLUGIN}@${this.pinnedVersion(java_versions_1.MAVEN_SOURCE_PLUGIN)}`, {

package/lib/java/java-maven-base.js

@@ -46,7 +46,7 @@ const PROJEN_TYPES_VERSION = require('../../package.json').version;
    *   update check.
  */
 class JavaMavenProject extends projen_1.github.GitHubProject {
-    static [JSII_RTTI_SYMBOL_1] = { fqn: "@xpertss/projen-types.JavaMavenProject", version: "0.0.25" };
+    static [JSII_RTTI_SYMBOL_1] = { fqn: "@xpertss/projen-types.JavaMavenProject", version: "0.0.26" };
     /** The root `pom.xml`. */
     pom;
     /** The canonical Java line the build targets (`1.8`, `17`, `21`, `25`). */

package/lib/java/java-service-project.js

@@ -17,7 +17,7 @@ const java_spring_boot_project_1 = require("./java-spring-boot-project");
  * repo use `JavaSpringBootProject`.
  */
 class JavaServiceProject extends java_spring_boot_project_1.JavaSpringBootProject {
-    static [JSII_RTTI_SYMBOL_1] = { fqn: "@xpertss/projen-types.JavaServiceProject", version: "0.0.25" };
+    static [JSII_RTTI_SYMBOL_1] = { fqn: "@xpertss/projen-types.JavaServiceProject", version: "0.0.26" };
     constructor(options) {
         super(options);
         this.addDependency('org.springframework.boot/spring-boot-starter-web');

package/lib/java/java-spring-boot-project.js

@@ -22,7 +22,7 @@ const REPACKAGE = { executions: [{ id: 'repackage', goals: ['repackage'] }] };
  * and a CDK deploy hook.
  */
 class JavaSpringBootProject extends java_maven_base_1.JavaMavenProject {
-    static [JSII_RTTI_SYMBOL_1] = { fqn: "@xpertss/projen-types.JavaSpringBootProject", version: "0.0.25" };
+    static [JSII_RTTI_SYMBOL_1] = { fqn: "@xpertss/projen-types.JavaSpringBootProject", version: "0.0.26" };
     /** The Spring Boot version (BOM and Maven plugin). */
     springBootVersion;
     constructor(options) {

package/lib/java/maven/maven-module.js

@@ -16,7 +16,7 @@ const maven_pom_1 = require("./maven-pom");
  * an artifact gets the same version.
  */
 class MavenModule extends projen_1.Component {
-    static [JSII_RTTI_SYMBOL_1] = { fqn: "@xpertss/projen-types.MavenModule", version: "0.0.25" };
+    static [JSII_RTTI_SYMBOL_1] = { fqn: "@xpertss/projen-types.MavenModule", version: "0.0.26" };
     /** Module directory, relative to the repo root. */
     dir;
     artifactId;

package/lib/java/maven/maven-pom.js

@@ -58,7 +58,7 @@ function key(c) {
  * `executions` and `dependencies` appended.
  */
 class MavenPom extends projen_1.Component {
-    static [JSII_RTTI_SYMBOL_1] = { fqn: "@xpertss/projen-types.MavenPom", version: "0.0.25" };
+    static [JSII_RTTI_SYMBOL_1] = { fqn: "@xpertss/projen-types.MavenPom", version: "0.0.26" };
     /** Path of the pom, relative to the project root. */
     filePath;
     groupId;

package/package.json

@@ -82,7 +82,7 @@
   "publishConfig": {
     "access": "public"
   },
-  "version": "0.0.25",
+  "version": "0.0.26",
   "jest": {
     "coverageProvider": "v8",
     "testMatch": [