@kosdev-code/kos-codegen-core 0.1.0-next.792 → 0.1.0-next.796

package/templates/polyglot-workspace/github/workflows/release.yml.template

@@ -0,0 +1,37 @@
+name: <%= nameDashCase %> release workflow
+on:
+  push:
+    tags:
+      - "[0-9]+.[0-9]+.[0-9]+"
+
+jobs:
+  release:
+    runs-on: ubuntu-latest
+    container:
+      image: ghcr.io/kosdev-code/kos-buildpublish/kos_builder:dockerimage
+      credentials:
+        username: ${{ github.actor }}
+        password: ${{ secrets.github_token }}
+      env:
+        KOS_KABTOOL_JAR: "/usr/local/lib/kabtool.jar"
+        JAVA_CMD: "java"
+    steps:
+      - name: Checkout Repository
+        uses: actions/checkout@v4
+        with:
+          repository: ${{ github.repository }}
+          token: ${{ secrets.GITHUB_TOKEN }}
+          path: ${{ github.event.repository.name }}
+          lfs: true
+
+      - name: Extract Version
+        run: |
+          echo KOSBUILD_VERSION=${GITHUB_REF#refs/tags/} >> $GITHUB_ENV
+
+      - name: Build and Publish
+        env:
+          KOSBUILD_SECRET_URL: ${{ secrets.KOSBUILD_SECRET_URL }}
+          KOSBUILD_SECRET_PASSWORD: ${{ secrets.KOSBUILD_SECRET_PASSWORD }}
+        working-directory: ./${{ github.event.repository.name }}
+        run: |
+          kos_build_handler.sh automation .github/build-release.json

package/templates/polyglot-workspace/java/README.md.template

@@ -0,0 +1,36 @@
+# Java backend
+
+Scaffold KOS Java modules here with the official KOS Maven archetypes — do not
+hand-roll the project structure.
+
+## Prerequisites
+
+- JDK 17 and Maven (see https://kosdev.com/articles/setup-you-kos-java-workspace/)
+
+## Creating a module
+
+```sh
+cd java
+mvn archetype:generate \
+  -DarchetypeGroupId=com.kos.archetypes \
+  -DarchetypeArtifactId=system-app
+```
+
+Archetypes (see https://kosdev.com/articles/kos_maven_archetypes/):
+
+| Archetype | Use for |
+| --- | --- |
+| `system-app` | The system app — the starting point of any KOS device |
+| `app` | Apps extending system functionality |
+| `sdk-app` | SDKs enabling inter-app collaboration |
+| `multi-module` | Multiple KABs from a single project |
+
+If your KOS CLI provides it, `kosui java:add` runs the archetype and updates
+the CI manifests in one step.
+
+## Conventions
+
+- Keep module versions at `0.0.0-SNAPSHOT` — releases are stamped from the git
+  tag by `build/release_version_prebuild.sh` (`mvn versions:set`).
+- Register each module's KAB in `.github/build-java.json` and
+  `.github/build-release.json` (`artifacts` arrays) so CI publishes it.

package/templates/polyglot-workspace/root/.gitignore.template

@@ -0,0 +1,5 @@
+.DS_Store
+target/
+*.log
+# repo-local toolchain provisioned by build/nodew.sh
+.kos/

package/templates/polyglot-workspace/root/README.md.template

@@ -0,0 +1,69 @@
+# <%= nameDashCase %>
+
+Polyglot KOS application repository: a Java backend and a KOS UI workspace that
+build side-by-side KOS artifacts (KABs) published to the KOS marketplace.
+
+## Layout
+
+| Path | Purpose |
+| --- | --- |
+| `ui/` | KOS UI workspace (Nx root lives here — run `npm`/`nx` commands inside `ui/`) |
+| `java/` | KOS Java backend (Maven; scaffold modules with the KOS Maven archetypes — see `java/README.md`) |
+| `build/` | Repo-level build orchestration scripts used locally and by CI |
+| `.github/` | CI workflows and `kos_build_handler` manifests (`build-*.json`) |
+
+The two halves never embed into each other: each produces its own KAB
+artifacts, published together by the release pipeline.
+
+## Local builds
+
+```sh
+./build/build-ui.sh        # npm ci + build all UI KABs
+./build/build-java.sh      # mvn build (skips cleanly while java/ is empty)
+./build/build-release.sh   # UI then Java (what the release pipeline runs)
+```
+
+**No toolchain? No problem.** The build scripts provision what's missing
+automatically (the `mvnw` pattern): `build/nodew.sh` fetches a pinned Node
+runtime and `build/jdkw.sh` a pinned Temurin JDK + Maven, each into the
+repo-local, gitignored `.kos/` on first use. Developers with their own
+toolchains/IDEs are never touched — the wrappers always defer to an existing
+install, so working on just `java/` in your own IDE needs nothing from here.
+
+Optional: `./build/docker-build.sh ui|java|release` runs a build inside the
+same container image CI uses (docker or podman; `docker login ghcr.io` for the
+image) — useful to reproduce a CI-environment issue, never required for
+development. Publishing is CI-only (tag push); no local flow publishes
+anything.
+
+## Releases (tag-driven)
+
+Push a semver tag to cut a release:
+
+```sh
+git tag 1.0.0 && git push origin 1.0.0
+```
+
+The release workflow derives `KOSBUILD_VERSION` from the tag, then
+`build/release_version_prebuild.sh` stamps it into every UI project's
+`.kos.json` (via `nx run-many --target=version`) and into the Maven POMs
+(`mvn versions:set`) before building and publishing all artifacts.
+
+## CI configuration
+
+Workflows run in the `kos_builder` container and publish through
+`kos_build_handler.sh`. Repository secrets required:
+
+- `KOSBUILD_SECRET_URL`
+- `KOSBUILD_SECRET_PASSWORD`
+
+The `default_keyset` in `.github/build-*.json` is org-specific (currently
+`<%= keyset %>`) — change it there if your organization uses a different
+keyset.
+
+## Adding artifacts
+
+Every KAB the repo produces must be listed in the `artifacts` arrays of
+`.github/build-ui.json` / `build-java.json` and the union kept in
+`build-release.json`. Update these when adding UI projects or Java modules
+(`kosui ci:sync` automates this where available).