Split tool-base into focused modules - #189
Merged
Merged
Conversation
The layer already publishes its contract: the `.410` uber POMs declare the complete flattened closure as pinned `runtime` entries. A constraint only adds information over a dependency when the module is not otherwise in the graph, and for consumers of the fat JARs every entry is — so a BOM would have had no reader. Probes against Maven Local established that Gradle derives platform variants for every POM-only module, mapping `<dependencyManagement>` — and only it — to constraints. Should an importable version table ever be wanted, an inline table in the existing uber POMs makes each coordinate serve as both library and platform; a separate BOM artifact is never needed. Phase B in the `compiler` repo is better served deriving its CLI contract from `compiler-cli`'s own resolved graph, which the IJ entries reach transitively — an imported IJ table could only agree with that or go stale. Records the rationale in project memory, since a `done` task file is deleted on merge, plus the feedback rule about keeping build machinery proportional. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Java-specific code was spread across two modules that each mixed concerns.
`tool-base` — the language-neutral foundation — also carried
`io.spine.tools.java`, `.java.fs` and `.java.javadoc`. `classic-codegen`
carried Java value types (the `Classpath`/`JavaClassName` proto pair, `Names`,
`Method`) welded to thin wrappers over JavaPoet and Roaster, so a consumer
needing only `Classpath` also dragged in both libraries.
The new `java-code` module takes every Java-specific piece from both, leaving
a clean layering:
tool-base language-neutral: io.spine.tools.{fs,code,proto,archive}
↑
java-code Java specialisation: io.spine.tools.java, .java.code,
.java.fs, .java.javadoc
↑
classic-codegen library wrappers only: .java.code.poet, .java.code.roaster
`java-code` depends on `tool-base` because `io.spine.tools.java.fs`
specialises the neutral `io.spine.tools.fs` abstractions; that edge is
intrinsic to the layering. Package names of the moved code are unchanged, so
consumers need a dependency addition rather than import edits.
The one coupling blocking a clean cut was `Method(MethodSpec)`, whose body was
`this(spec.toString())`. It is replaced by `MethodSpec.toMethod()` in
`PoetExts.kt`, which moves to `io.spine.tools.java.code.poet`; `RoasterExts.kt`
moves to `.roaster`. `@VisibleForTesting` leaves `Method(String)`, which is now
the primary constructor rather than a test entry point.
Two test fixtures had to follow the moved code. `SourceFileSpec` compiles
against generated Protobuf types in the `testFixtures` source set of
`tool-base`, which that module's own tests still use, so `java-code` consumes
them via `testFixtures(project(":tool-base"))` instead of the fixtures being
split. `JavaLangExtsSpec` needs the hand-written `given.annotation.Schedule`,
which lives in a `test` source set and is therefore unshareable; nothing else
referenced it, so it moved outright.
Verified: full `build` and `dokkaGenerate` pass; the two JARs share no class;
`java-code` carries neither JavaPoet nor Roaster on its compile classpath.
Downstream repos need `ToolBase.javaCode` added, and `core-jvm-compiler` needs
its Poet and Roaster imports repointed at the new sub-packages.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Adds the section for the new `java-code` module and re-resolves the report for `classic-codegen`, which no longer compiles Protobuf. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Continues the `java-code` extraction, leaving `tool-base` language-neutral.
Two more modules take the remaining language-specific packages:
js-code io.spine.tools.js.code, io.spine.tools.js.fs
dart-code io.spine.tools.dart, io.spine.tools.dart.fs
`tool-base` now holds only `io.spine.tools.{fs,code,proto,archive,io,kotlin,
type,…}`.
Both new modules depend on `tool-base` for the same reason `java-code` does:
their `fs` packages specialise the neutral `io.spine.tools.fs` abstractions
(`DefaultPaths`, `AbstractDirectory`, `SourceDir`, `FileReference`,
`ExternalModules`, `FileWithImports`) and `io.spine.tools.code`
(`SourceSetName`, `Element`). `dart-code` also needs `Logging`, since
`ImportStatement` is `WithLogging`. Neither package carries `.proto` files, so
neither module applies the Protobuf plugins.
Package names are unchanged, so consumers need a dependency addition rather
than import edits. Cross-repo, only `mc-js` consumes `io.spine.tools.js.*`;
nothing consumes `io.spine.tools.dart.*`.
Verified: `clean build dokkaGenerate` passes; the `tool-base` JAR no longer
carries any `io/spine/tools/{java,js,dart}` class, and each new JAR holds
exactly its own two packages.
Downstream: `config` needs `jsCode` and `dartCode` constants; `mc-js` needs
`ToolBase.jsCode`.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Adds the sections for the new `js-code` and `dart-code` modules. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The annotation makes the compiler verify that the field really is a valid serialization member, catching a wrong type, scope, or spelling that would otherwise be ignored silently.
Moves `io.spine.tools.fs` out of `tool-base` into its own module, which
depends on nothing but Base and now sits below `tool-base` in the graph.
Extracting the package as it stood was impossible: a three-package cycle ran
across the cut, harmless inside a single module but fatal as a circular
Gradle project dependency.
io.spine.tools.fs --> io.spine.tools.code.SourceSetName
(Generated, SourceRoot)
io.spine.tools.code --> io.spine.tools.titlecaseFirstChar
(SourceSetName, SourceSetBasedName)
io.spine.tools (root) --> io.spine.tools.fs.DirectoryName
(StandardTypesExts)
The cycle is severed at its source rather than by dragging
`io.spine.tools.code` along or splitting that package across two artifacts:
`Generated.dir` and `SourceRoot.subDir` now take a plain `String` source-set
name instead of `SourceSetName`. This trades the type safety of those two
methods for a layering that is real rather than a re-parcelling.
`tool-base` keeps a one-way dependency on `fs`, since
`io.spine.tools.proto.fs.Directory` extends `SourceCodeDirectory` and the
`StandardTypes` extensions accept `DirectoryName`.
With `SourceSetName` out of the way, `java-code` and `js-code` now depend on
`fs` alone — `tool-base` has left their compile classpath entirely.
`dart-code` still needs `tool-base`, because `ImportStatement` is an
`io.spine.tools.code.Element` and `ProtocPluginPath`/`PubCache` branch on
`io.spine.tools.OsFamily`; neither type is file-system related, so neither
belongs in `fs`.
Verified: `clean build dokkaGenerate` passes; the `fs` JAR holds exactly the
17 classes of `io/spine/tools/fs` and `tool-base` holds none of them.
BREAKING: `mc-js` passes `SourceSetName` to `generated().dir(...)` at 8 call
sites and must pass a `String` instead. `compiler` and `core-jvm-compiler`
have no call sites of the changed methods.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Adds the section for the new `fs` module. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Collects the Protobuf-specific parts of `tool-base` into one module, continuing the split that produced `fs`, `java-code`, `js-code` and `dart-code`: io.spine.tools.proto.fs the `proto` source directory io.spine.tools.type descriptor set merging, known-type extension io.spine.tools.code.proto the code generator request src/main/proto spine/tools/proto/proto.proto The proto source set generates into `io.spine.tools.proto.code`, so the module is named after the package its own sources produce. `tool-base` keeps the Protobuf plugins: `src/main/proto` is now empty, but its `testFixtures` source set still holds fourteen `.proto` files. Dependencies of the moved code: `proto.fs.Directory` extends `SourceCodeDirectory`, so `fs` is API; `FileDescriptorSuperset` reads descriptor sets out of archives via `io.spine.tools.archive`, which stays in `tool-base` and does not reach the public API, so that one is implementation. `DirectorySpec` moves here from `java-code`, where the earlier extraction had parked it because it parents the `proto` root on `DefaultJavaPaths`. It follows its subject; `java-code` becomes a test dependency, which is acyclic since `java-code` depends only on `fs`. Two couplings surfaced only at compile time, neither visible to an import scan. `FileDescriptorSupersetTest` uses `PersonProto`, `ProjectProto` and `TaskProto`, generated from the `tool-base` fixtures into `io.spine.tools.type` — the same package as the code under test, hence no import to reveal them. And those fixtures carry gRPC-generated code whose versions `tool-base` supplies through a resolution strategy rather than through the coordinates, so consuming them without that strategy fails with an empty version. Both are handled the way `java-code` already handles them. Verified: `clean build dokkaGenerate` passes; `proto-code` holds all four packages and `tool-base` holds none of them. Consumers keep their imports, package names being unchanged. Downstream repos need `ToolBase.protoCode` added: `core-jvm-compiler`, `compiler`, `ProtoTap`, `base-libraries`. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Adds the section for the new `proto-code` module. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The `person`, `project` and `task` fixtures declared `package spine.tools.type` and `java_package = "io.spine.tools.type"` — the same Java package that `proto-code` now owns in its main sources. Since `java-test-fixtures` publishes a `-test-fixtures` artifact, the package spanned two published JARs. They move to `spine/test/tools/type/` under `spine.test.tools.type` / `io.spine.test.tools.type`, matching every other fixture in this source set, which already uses the `spine.test.*` namespace. Their cross-imports move with them. Two consumers follow: `FileDescriptorSupersetTest` gains explicit imports for `PersonProto`, `ProjectProto` and `TaskProto` — it needed none while the fixtures shared its package — and `SourceFileSpec` re-points its `ProjectServiceGrpc` import. No test asserts on the fixture type URLs, and the one path assertion pins only a file name, so the namespace change is inert. Verified with `--no-build-cache`: `io.spine.tools.type` is now published by `proto-code` alone, and `io.spine.test.tools.type` by the fixtures alone. The cache matters here — see the memory note added alongside. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Reflects the renamed test fixture namespace. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
`StandardTypesExts.kt` mixed a plain string helper with six extensions over
`java.io.File`, `java.nio.file.Path` and `Supplier<String>` that exist to
resolve a `DirectoryName` — an `io.spine.tools.fs` type. The six move to
`io.spine.tools.fs.PathAndFileExts`, published under the JVM name `Paths`;
`titlecaseFirstChar` stays behind as the sole occupant of `StandardTypes`.
`StandardTypeExtensionsSpec` splits the same way: its five path and file cases
become `PathAndFileExtsSpec` in the `fs` module, and the title-case case stays.
The moved `Path` case now builds paths with `Path.of` rather than
`java.nio.file.Paths`, whose simple name the new file claims for its own facade.
Three call sites follow the code. Two were Kotlin imports of
`io.spine.tools.{div, resolve}`; the third, in `CodeGenerationAction`, imported
the *JVM facade* — `io.spine.tools.StandardTypes.toAbsoluteFile` — a spelling
that shares no text with the Kotlin package and so hides from the obvious
grep.
With these gone, no `tool-base` source references `io.spine.tools.fs` at all.
Its `api(project(":fs"))` is now dead weight, kept only because `plugin-base`
and `protobuf-setup-plugins` still reach `fs` through it; dropping it is a
follow-up, not part of this change.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Moving the path and file extensions out of `tool-base` left no source in that
module referencing `io.spine.tools.fs`, so its `api(project(":fs"))` had become
pure re-export: `plugin-base` and `protobuf-setup-plugins` used `fs` types
directly while declaring nothing, reaching them through `tool-base` instead.
`tool-base` drops the dependency, and the two real users declare their own, at
the scope their code calls for:
plugin-base api — `GeneratedSourceRoot` and `GeneratedSourceSet`
are public classes extending `AbstractDirectory`
protobuf-setup-plugins implementation — `DescriptorsDir` appears only in a
private extension property, `DirectoryName` and
`resolve` only inside function bodies
All six modules that reference `io.spine.tools.fs` now declare it; `tool-base`
has no project dependencies left at all.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Finishes the split of `tool-base` by moving out its last three packages: kotlin-code io.spine.tools.kotlin code io.spine.tools.code archive io.spine.tools.archive `tool-base` is left with `OsFamily` and its `package-info` — four classes — plus the `testFixtures` source set that `java-code` and `proto-code` share. The `code` extraction was cheap because `c9a9cad3` had just replaced `io.spine.tools.titlecaseFirstChar` with `io.spine.string.titleCase` in `SourceSetName` and `SourceSetBasedName`, removing the last edge from that package back to the `io.spine.tools` root. `code` now depends on Base alone, as do `kotlin-code` and `archive` — the latter also on `Logging`, since `EntryLookup` is `WithLogging`. Dependencies follow where the types actually appear: `api` for `plugin-base`, whose `JavaConfigurationName` and `SourceSet.named` carry `SourceSetName` in their signatures; `implementation` elsewhere, since `dart-code` implements `Element` on a package-private class and reads `OsFamily` inside method bodies, and `jvm-tool-plugins` and `protobuf-setup-plugins` keep `SourceSetName` internal. `proto-code` swaps its `tool-base` dependency for `archive`, the only part it ever used. Two dependencies go as dead weight: `plugin-base` on `tool-base`, which it needed only for `io.spine.tools.code`, and `tool-base` on `Logging`, since nothing there logs any more. One latent break surfaced. `:code:dokkaGenerateModuleHtml` failed because `SourceSetBasedName` still linked to `[titlecassed][String.titlecaseFirstChar]`, a symbol `c9a9cad3` had removed. The link was already dead inside `tool-base`; giving the package its own module, and so its own Dokka run, is what made it fail. It now points at `[title-cased][String.titleCase]`, the utility the code calls. Verified with `clean build dokkaGenerate --no-build-cache`: each new JAR holds exactly its own package. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Five of the thirteen Protobuf fixtures in `tool-base` generated types that no
test in this repository referenced, and nothing imported them from the protos
that stay:
spine/method/messages_with_vbuilders.proto
spine/method/rejections.proto
spine/method/uuid_messages.proto
spine/test/code/generate/nested_field_scanner_test.proto
spine/test/code/outer_class_test.proto
They were found by mapping every generated top-level type back to its source
proto through the `// source:` header of the generated Java, then searching all
199 test sources for each type name, and separately for the proto file names and
Protobuf packages in case of string references. Two false positives had to be
discarded by hand: `Project` and `Task` match Gradle's own types throughout
`buildSrc` and the plugin modules, not the fixture messages.
The remaining eight move to a `fixtures` module: the `source_file_test` family
that `java-code`'s `SourceFileSpec` reads, and the `person`/`project`/`task`
trio behind `proto-code`'s `FileDescriptorSupersetTest`.
The module is deliberately **not published**. The root build script leaves it
out of `spinePublishing.modules`, and both that exclusion and the module's own
build script say why: these declarations are renamed and deleted as our tests
change, so nothing downstream may bind to them. `:fixtures:tasks` registers no
`publish*` task at all. The protos keep their `spine.test.*` namespace, which
marks them as fixtures and keeps them clear of the production packages.
They sit in the module's `main` source set rather than in `testFixtures`, so
consumers write a plain `testImplementation(project(":fixtures"))` and the gRPC
runtime that `project.proto`'s service needs travels with it as `api`.
With the fixtures gone, `tool-base` sheds `java-test-fixtures`, the Protobuf
plugins and gRPC: two classes and four lines of dependencies.
Verified with `clean build dokkaGenerate --no-build-cache`.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
After the package-by-package split, the module held one enum —
`io.spine.tools.OsFamily` — plus its `package-info` and test.
The enum is not moved anywhere: Base Libraries already publishes the same one
as `io.spine.environment.OsFamily` in its `environment` module. `dart-code`,
its only consumer, now depends on `Base.environment` and imports that;
`ProtocPluginPath` and `PubCache` read it inside method bodies, so the
dependency stays an implementation one.
No version bump was needed — `spine-environment:2.0.0-SNAPSHOT.440` already
carries the enum.
The repository keeps its name: `rootProject.name` and the `gitHub("tool-base")`
publishing destination are untouched. Only the module is gone.
Verified with `clean build dokkaGenerate --no-build-cache`.
Follow-up for the `config` repository, not done here because it is a shared
submodule affecting every consumer: `ToolBase.lib` still names the
`io.spine.tools:tool-base` artifact, which will no longer be published.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Contributor
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 158 out of 271 changed files in this pull request and generated no new comments.
Suppressed comments (1)
code/src/main/java/io/spine/tools/code/IndentedLine.java:61
IndentedLine.of(Indent, String)callsof(code), but there is noof(String)overload in this class and there is no static import forLine.of(..). As written, this does not compile. UseLine.of(code)to construct the underlyingLineinstance.
Base Libraries #959 updated the caller name in `KnownTypes.Holder.extendWith`
from `io.spine.tools.type.MoreKnownTypes` to `io.spine.tools.proto.type.MoreKnownTypes`,
matching the package this repository moved the class to. Verified in the
published artifact before re-enabling anything:
ldc // String io.spine.tools.proto.type.MoreKnownTypes
invokestatic // InvocationGuard.allowOnly
The three tests parked against base-libraries#958 now run again, with no
`@Disabled` left behind:
proto-code MoreKnownTypesTest.extendKnownTypes
proto-code MergedDescriptorSetSpec `extend the known types`
protobuf-setup-plugins ProtoFilesSpec `supply a merged file set ...`
`proto-code` reports 17 tests, `protobuf-setup-plugins` 25, none skipped.
The last of the three is the one that matters outside this repository: it
exercises `ProtoFiles.collect`, so the Gradle plugin no longer throws
`SecurityException` for consumers.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Contributor
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 158 out of 271 changed files in this pull request and generated no new comments.
Suppressed comments (1)
buildSrc/src/main/kotlin/io/spine/dependency/local/ToolBase.kt:40
- This PR retires the
tool-basemodule, butToolBasestill declareslib = "$group:tool-base:$version"and its KDoc says “Artifacts of thetool-basemodule”. Keeping this constant around makes it easy to accidentally depend on a no-longer-published artifact.
Reflects the Base bump to `2.0.0-SNAPSHOT.441`. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Contributor
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 158 out of 271 changed files in this pull request and generated no new comments.
Suppressed comments (1)
code/src/main/java/io/spine/tools/code/IndentedLine.java:61
var pure = of(code);relies on inheritingLine.of(String)via a static method call that looks like a self-call ofIndentedLine.of(...). Qualifying it asLine.of(code)avoids confusion (and prevents accidental recursion if anof(String)overload is introduced here later).
alexander-yevsyukov
disabled auto-merge
August 19, 2026 14:13
The unqualified `of(code)` bound to the inherited `Line.of(String)`, which reads like a self-call. Qualifying it names where the factory lives and keeps a future `IndentedLine.of(String)` overload from silently capturing the call and changing `pure` from a `Line` to an already-indented one. Raised by Copilot on PR #189. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
JavaScript and Dart are not supported languages in v2.x — TypeScript covers the front end for now — so the modules extracted for them earlier in this branch are removed rather than published: js-code io.spine.tools.js.code, io.spine.tools.js.fs (16 files) dart-code io.spine.tools.dart, io.spine.tools.dart.fs (16 files) Nothing in this repository referenced either module: no build script depended on them and no source imported `io.spine.tools.js` or `io.spine.tools.dart` outside the modules themselves. `dart-code` had no consumer anywhere in the SDK. `mc-js` is the one repository that used `io.spine.tools.js.*`, and it loses its source of those types with this change. Verified with `clean build dokkaGenerate --no-build-cache`. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
alexander-yevsyukov
added a commit
to SpineEventEngine/config
that referenced
this pull request
Aug 19, 2026
JavaScript and Dart are not supported languages in v2.x, so SpineEventEngine/tool-base#189 no longer publishes `js-code` or `dart-code`. Declaring constants for them would point at artifacts that will not exist. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
alexander-yevsyukov
enabled auto-merge
August 19, 2026 14:56
armiol
approved these changes
Aug 19, 2026
This was referenced Aug 19, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Splits the monolithic
tool-basemodule into focused modules, one per concern,and retires the module itself. Package names are preserved throughout, so
consumers need dependency additions rather than import edits — with the
exceptions called out under Breaking changes.
Why
tool-basehad accumulated everything: file-system abstractions, Java code-generationtypes, Protobuf descriptor handling, archive reading and language-neutral code types.
Anyone needing one part compiled against all of them.
classic-codegenhad the sameproblem on a smaller scale — its
Classpathproto type dragged in JavaPoet and Roaster.The result
fsio.spine.tools.fscodeio.spine.tools.codearchiveio.spine.tools.archivekotlin-codeio.spine.tools.kotlinjava-codeio.spine.tools.java,.java.code,.java.fs,.java.javadocproto-codeio.spine.tools.proto.code,.proto.fs,.proto.typefixturesclassic-codegenkeeps only the library wrappers, inio.spine.tools.java.code.poetand
.roaster. Thetool-basemodule is gone; the repository keeps its name.JavaScript and Dart are not supported in v2.x. Modules were extracted for them
mid-branch and then removed — TypeScript covers the front end for now. Nothing in this
repository referenced them;
mc-jsis the one repository that usedio.spine.tools.js.*and loses its source of those types.Breaking changes
Generated.dirandSourceRoot.subDirtake aStringsource-set nameinstead of
SourceSetName. Extractingio.spine.tools.fswas otherwiseimpossible: a three-package cycle ran across the cut —
fs → code.SourceSetName → io.spine.tools.titlecaseFirstChar → fs.DirectoryName— harmless inside onemodule, fatal as a circular Gradle project dependency.
mc-jspassesSourceSetNameat 8 call sites and must pass aString. The blank-name checkSourceSetNameperformed is preserved inSourceRoot.subDir.io.spine.tools.OsFamilyis gone. Base Libraries already publishes the sameenum as
io.spine.environment.OsFamily.io.spine.tools.java.code.{classSpec, constructorSpec, methodSpec, codeBlock}move to
…code.poet, andfullTextNormalizedto…code.roaster.Method(MethodSpec)is replaced byMethodSpec.toMethod()in thepoetpackage.io.spine.tools.type→io.spine.tools.proto.typeandio.spine.tools.code.proto→io.spine.tools.proto.code, consolidatingproto-codeunder one package root. This required a matching change to theruntime guard in
KnownTypes.Holder.extendWith, delivered byAllow
extendWithfor the newMoreKnownTypespackage base-libraries#959 and picked up here via Base2.0.0-SNAPSHOT.441.io.spine.tools.js.*andio.spine.tools.dart.*are gone, along withlanguage support for JavaScript and Dart.
Notable details
fixturesis deliberately unpublished. It is excluded fromspinePublishing.modules, and:fixtures:tasksregisters nopublish*task.Five fixture protos that no test referenced were deleted.
person/project/taskprotos declared
io.spine.tools.type, the packageproto-codenow owns, so thepackage spanned two published JARs. They moved to
io.spine.test.tools.type.apiwhere a type reaches a publicsignature,
implementationotherwise. Dependencies that became dead were dropped.Verification
./gradlew clean build dokkaGenerategreen, run with--no-build-cacheat eachstep. Artifact contents were checked per module: each JAR holds exactly its own
packages, no package is published by two artifacts, and
java-codecarries neitherJavaPoet nor Roaster.
Downstream follow-ups
config— Declare the modulestool-basewas split into config#748 declares the new modules and deprecatesToolBase.lib. It must not merge until2.0.0-SNAPSHOT.420is published.mc-js— losesio.spine.tools.js.*entirely, and has 8SourceSetNamecall sites.core-jvm-compiler,compiler,ProtoTap,base-libraries— new coordinates;core-jvm-compileralso needs thepoet/roasterandio.spine.tools.{div,resolve}→io.spine.tools.fs.{div,resolve}import moves.🤖 Generated with Claude Code