werkator/docs/prs/2026-10-15-PR#163-package-de-javagil.md

PR#163: The code moves from de.hoennig.werkator to de.javagil.werkator

Version: patch

WARNING: This document describes only the change applied in this PR. It may already be outdated once the next PR is merged. Historic PR-documentation is not maintained along with new PRs — treat it as a snapshot, not as current documentation.

Related Links

• werkregie PR#86: Names follow javagil.de

Problem

The shared workflow (werkregie PR#86) says that names follow javagil.de. On the JVM, packages, Maven groups and Gradle plugin IDs start with de.javagil.<repo>. Werkator's code lives in de.hoennig.werkator, and its Maven group is de.hoennig. The workflow also says that a PR which moves many files starts only when no other PR of the repository is open, and does only the move.

Non-Goals

• No change of behaviour, of an API, of a route or of a configuration key.
• The Docker label org.hoennig.werkator stays. It is no package, the rule does not name labels, and a new label would leave the containers of a running Docker host (vm4006) out of the clean-up of stale containers.
• Historic PR documents and plan steps keep their old paths: they are snapshots and are not maintained.
• No refactoring along the way.

Specification

Feature: the code lives under de.javagil.werkator

Scenario#163.01: Every class and every test lives under de.javagil.werkator!

So that the package follows the naming rule of the shared workflow.

• Given the sources under src/main/kotlin and src/test/kotlin
• When the build compiles and tests them
• Then every package starts with de.javagil.werkator
  • and the Maven group is de.javagil
  • and no source file names de.hoennig.werkator any more

Verified by

• The build (./gradlew build): it compiles every class and runs every spec at its new place; ktlint refuses a package that does not match its directory.

Scenario#163.02: The nightly mutation build measures the moved classes!

So that the Mutation-CRAP gate keeps judging every method after the move.

• Given the PIT configuration in build.gradle.kts
• When the nightly build mutation runs on main after the merge
• Then targetClasses and targetTests select de.javagil.werkator.*
  • and the five specs left out of PIT are left out by their new names

Verified by

• The first nightly run on main after the merge (manual check).

Solution

• git mv of src/main/kotlin/de/hoennig/werkator and src/test/kotlin/de/hoennig/werkator to de/javagil/werkator, then de.hoennig.werkator replaced by de.javagil.werkator in every source, so git sees renames.
• build.gradle.kts: group = "de.javagil", and the PIT targetClasses, targetTests and excluded specs by their new names.
• application-server.yml: the logging level for de.javagil.werkator.
• AGENTS.md, the architecture and writing-tests skills, docs/llms.md and the source links of RFC 0002 and RFC 0004 name the new package.
• docs/agentic-workflow.md is the current master copy of werkregie, including the naming rule and the rule for a PR that moves many files.
• Version 1.43.3, with an internal entry in the release notes.

Where a class name is visible outside the code was checked before the move:

Place	Finding
Start, systemd unit, runtime bundle	java -jar; Spring Boot writes the start class into the jar itself
Stored JSON (results, metrics, state)	no type names, no @JsonTypeInfo
Plugin IDs, META-INF, kotest settings	none of Werkator's own
Logging levels	only application-server.yml; no host file on mih09 names the old package

Open Questions

• TODO.mutation: PIT's .pitest/history.bin in main's worktree on mih09 knows the classes only by their old names. The first nightly run after the merge therefore measures every class anew, without the incremental history. A full local run took 1 h 14 min with 4 threads; on mih09 with 2 threads it may come close to the build timeout of 3 h. Watch that run; if it times out, start it once more, as the history of the first run is then partly written.
• TODO.vm4006: whether a host file on vm4006 sets a logging level for de.hoennig.werkator was not checked; it is only a level, the instance runs without it.