IKE Workspace Reactor Example

Note (2026-05-20 / 2026-05-23): This workspace was originally named ike-example-ws, with subprojects example-project and its (the ike-example-its repo). All four were renamed under the canonical naming policy in IKE-Network/ike-issues#467 so the artifact ID, git repo name, on-disk directory, and workspace.yaml subproject key all match. The workspace was further renamed from workspace-example to workspace-reactor-example under the -wsr aggregator-reactor suffix policy — see the arch-workspace-and-workspace-reactor topic in ike-lab-documents. GitHub redirects keep old clone URLs working.

Workspace aggregator that orchestrates three consumer-side subprojects (doc-example, project-example, integration-tests-example) against the IKE foundation repos (ike-tooling, ike-docs, ike-platform) consumed from Nexus. Clone this repo and run mvn ws:scaffold-init to pull down the subprojects and build the cascade as a single reactor.

What this workspace is for

• Local development of the consumer-side subprojects against released foundation versions in one editor / one command.
• Coordinated releases of the subprojects via mvn ws:release-publish.
• End-to-end integration tests that exercise external Nexus consumption of the post-IKE-Network/ike-issues#321 classifier-canonical doc shape (<packaging>pom</packaging> + <classifier>adoc</classifier> source attachment).

Bootstrap

git clone https://github.com/IKE-Network/workspace-reactor-example.git
cd workspace-reactor-example

mvn ws:scaffold-init # clone subprojects per workspace.yaml
mvn ws:overview      # print the workspace dashboard
mvn clean install    # build the full cascade

Foundation repos (consumed from Nexus, NOT workspace subprojects)

These are the upstream IKE infrastructure projects this workspace consumes at their released versions. They are intentionally not managed by this workspace — they release on their own cadence via their own ike:release-publish. See the comment block in workspace.yaml for the rationale (self-bootstrap for ike-tooling, parent-cycle avoidance for ike-platform).

Repo	Artifact	Purpose
ike-tooling	network.ike.tooling:*	Release orchestration, BOM generation, AsciiDoc utilities; source of ike-maven-plugin
ike-docs	network.ike.docs:*	AsciiDoc plumbing: ike-doc-maven-plugin (render goals), Koncept extension, fonts, DocBook XSL, shared resources
ike-platform	network.ike.platform:*	Consumer-facing parent: ike-parent, ike-bom, ike-workspace-maven-plugin

Subprojects (managed by this workspace)

These are the consumer-side demos the workspace orchestrates. ws:scaffold-init clones them into this directory; ws:release-publish releases them in dependency order.

Repo	Artifact	Purpose
doc-example	network.ike.examples:doc-example	Doc-only template — <packaging>pom</packaging> with adoc source classifier
project-example	network.ike.examples:project-example	Hybrid Java+docs template — <packaging>jar</packaging> with optional adoc classifier when src/docs/asciidoc/ exists
integration-tests-example	network.ike.examples:integration-tests-example	Optional integration-test harness; a file-activated profile picks it up when present. Split from this workspace in #343 so the IT harness can evolve on its own cadence.

See workspace.yaml for version pins and dependency declarations.

Release Cascade

ike-tooling → ike-docs → ike-platform → [ workspace: { doc-example, project-example, integration-tests-example } → workspace-reactor-example ]

ike-tooling is bootstrapped out-of-band (it releases itself using the plugin it produces). The foundation tier is then orchestrated by cascade-foundation-publish (in ike-platform's ike-workspace-maven-plugin), which walks ike-tooling → ike-docs → ike-platform and then invokes the workspace's own ws:release-publish to release the three subprojects in dependency order, finishing with the workspace root.

Integration Tests

See integration-tests-example/README.md for the IT suite layout and how to add new end-to-end tests.

Doc as Code + LLM-Friendly

This workspace follows the IKE Network's doc-as-code philosophy: build conventions, documentation standards, and AI-assistant guidance live as versioned Markdown files in ike-build-standards and are unpacked into every consumer's .claude/standards/ at the validate phase. When a developer — or Claude itself — opens any IKE project, the agent reads those standards and applies them automatically; contributors don't have to memorize the conventions.

The standards most directly relevant to a workspace consumer are IKE-WORKSPACE.md (workspace.yaml layout, ws:* goals) and IKE-RELEASE.md (cascade procedure). See the full inventory.

Links

• Documentation: https://ike.network/workspace-reactor-example/
• Subproject sites (each publishes its own top-level gh-pages):
  • doc-example — documentation-only example
  • project-example — Java + docs example
  • integration-tests-example — integration test harness
• Foundation repos (consumed from Nexus, not workspace subprojects): ike-tooling · ike-docs · ike-platform
• Build standards: ike-build-standards
• Issues: IKE-Network/ike-issues (cross-project tracker)
• Source: IKE-Network/workspace-reactor-example

History

Split from the archived ike-pipeline repo to resolve a Maven extension-plugin reactor-load cycle. See IKE-Network/ike-issues#216.

Developer Setup

New to IKE development? The Developer Environment guide covers IDE configuration, JDK 25 setup, and the tooling conventions every IKE workspace expects — start there before your first build.