Skip to content

Split tool-base into focused modules - #189

Merged
alexander-yevsyukov merged 36 commits into
masterfrom
java-code-module
Aug 19, 2026
Merged

Split tool-base into focused modules#189
alexander-yevsyukov merged 36 commits into
masterfrom
java-code-module

Conversation

@alexander-yevsyukov

@alexander-yevsyukov alexander-yevsyukov commented Aug 18, 2026

Copy link
Copy Markdown
Contributor

Splits the monolithic tool-base module 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-base had accumulated everything: file-system abstractions, Java code-generation
types, Protobuf descriptor handling, archive reading and language-neutral code types.
Anyone needing one part compiled against all of them. classic-codegen had the same
problem on a smaller scale — its Classpath proto type dragged in JavaPoet and Roaster.

The result

Base
 ▲
 ├── fs ◄──────── plugin-base, proto-code, java-code, protobuf-setup-plugins
 ├── code ◄────── plugin-base, jvm-tool-plugins, protobuf-setup-plugins,
 │                java-code (test)
 ├── archive ◄─── proto-code
 └── kotlin-code
New module Package(s)
fs io.spine.tools.fs
code io.spine.tools.code
archive io.spine.tools.archive
kotlin-code io.spine.tools.kotlin
java-code io.spine.tools.java, .java.code, .java.fs, .java.javadoc
proto-code io.spine.tools.proto.code, .proto.fs, .proto.type
fixtures test-only Protobuf declarations — not published

classic-codegen keeps only the library wrappers, in io.spine.tools.java.code.poet
and .roaster. The tool-base module 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-js is the one repository that used
io.spine.tools.js.* and loses its source of those types.

Breaking changes

  1. Generated.dir and SourceRoot.subDir take a String source-set name
    instead of SourceSetName. Extracting io.spine.tools.fs was otherwise
    impossible: a three-package cycle ran across the cut — fs → code.SourceSetName → io.spine.tools.titlecaseFirstChar → fs.DirectoryName — harmless inside one
    module, fatal as a circular Gradle project dependency. mc-js passes
    SourceSetName at 8 call sites and must pass a String. The blank-name check
    SourceSetName performed is preserved in SourceRoot.subDir.
  2. io.spine.tools.OsFamily is gone. Base Libraries already publishes the same
    enum as io.spine.environment.OsFamily.
  3. io.spine.tools.java.code.{classSpec, constructorSpec, methodSpec, codeBlock}
    move to …code.poet, and fullTextNormalized to …code.roaster.
    Method(MethodSpec) is replaced by MethodSpec.toMethod() in the poet package.
  4. io.spine.tools.typeio.spine.tools.proto.type and
    io.spine.tools.code.protoio.spine.tools.proto.code, consolidating
    proto-code under one package root. This required a matching change to the
    runtime guard in KnownTypes.Holder.extendWith, delivered by
    Allow extendWith for the new MoreKnownTypes package base-libraries#959 and picked up here via Base
    2.0.0-SNAPSHOT.441.
  5. io.spine.tools.js.* and io.spine.tools.dart.* are gone, along with
    language support for JavaScript and Dart.

Notable details

  • fixtures is deliberately unpublished. It is excluded from
    spinePublishing.modules, and :fixtures:tasks registers no publish* task.
    Five fixture protos that no test referenced were deleted.
  • Test fixtures left the production namespace: the person/project/task
    protos declared io.spine.tools.type, the package proto-code now owns, so the
    package spanned two published JARs. They moved to io.spine.test.tools.type.
  • Dependency scopes follow the code: api where a type reaches a public
    signature, implementation otherwise. Dependencies that became dead were dropped.

Verification

./gradlew clean build dokkaGenerate green, run with --no-build-cache at each
step. Artifact contents were checked per module: each JAR holds exactly its own
packages, no package is published by two artifacts, and java-code carries neither
JavaPoet nor Roaster.

Caching note: with org.gradle.caching=true, renaming a generated package leaves
the old classes restorable from the build cache, so artifact checks need
--no-build-cache. Also, clean build in one invocation is unreliable under
org.gradle.parallel=true — run clean separately.

Downstream follow-ups

  • configDeclare the modules tool-base was split into config#748 declares the new modules and deprecates
    ToolBase.lib. It must not merge until 2.0.0-SNAPSHOT.420 is published.
  • mc-js — loses io.spine.tools.js.* entirely, and has 8 SourceSetName call sites.
  • core-jvm-compiler, compiler, ProtoTap, base-libraries — new coordinates;
    core-jvm-compiler also needs the poet/roaster and
    io.spine.tools.{div,resolve}io.spine.tools.fs.{div,resolve} import moves.

🤖 Generated with Claude Code

alexander-yevsyukov and others added 30 commits August 18, 2026 18:53
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>
Copilot AI review requested due to automatic review settings August 19, 2026 00:11

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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) calls of(code), but there is no of(String) overload in this class and there is no static import for Line.of(..). As written, this does not compile. Use Line.of(code) to construct the underlying Line instance.

@alexander-yevsyukov alexander-yevsyukov moved this from 🏗 In progress to In Review in v2.0 Aug 19, 2026
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>
Copilot AI review requested due to automatic review settings August 19, 2026 13:19

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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-base module, but ToolBase still declares lib = "$group:tool-base:$version" and its KDoc says “Artifacts of the tool-base module”. 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>

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 inheriting Line.of(String) via a static method call that looks like a self-call of IndentedLine.of(...). Qualifying it as Line.of(code) avoids confusion (and prevents accidental recursion if an of(String) overload is introduced here later).

alexander-yevsyukov and others added 2 commits August 19, 2026 15: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>
Copilot AI review requested due to automatic review settings August 19, 2026 14:52
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>

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Copilot reviewed 183 out of 269 changed files in this pull request and generated no new comments.

@alexander-yevsyukov
alexander-yevsyukov merged commit 43ea6af into master Aug 19, 2026
11 checks passed
@alexander-yevsyukov
alexander-yevsyukov deleted the java-code-module branch August 19, 2026 15:06
@github-project-automation github-project-automation Bot moved this from In Review to ✅ Done in v2.0 Aug 19, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: ✅ Done

Development

Successfully merging this pull request may close these issues.

3 participants