build: extract shared Gradle logic into buildSrc conventions - #206
Merged
Conversation
Contributor
Test results 63 files 63 suites 55s ⏱️ Results for commit 00dfaed. ♻️ This comment has been updated with latest results. |
Every module build file carried its own copy of the same setup: the Java toolchain five times, the test configuration four times, and the ~45-line publishing boilerplate (licence, developer, SCM, repository) three times. Jacoco was applied to only two of the five modules, so :app produced no coverage report despite having 15 test classes. Two precompiled script plugins now own that: - titan.java-conventions: toolchain 25, javac options (--release, UTF-8, -Xlint:deprecation/unchecked), JUnit Platform + minestom.inside-test, Jacoco with an XML report wired to test - titan.publish-conventions: the "maven" publication with coordinates, POM metadata and the OneLiteFeather repository. Modules keep only what actually differs - artifactId, POM name/description and the artifacts. The Shadow plugin version is declared once in the root build with `apply false` instead of being repeated in :app and :setup. No change to build output. Verified against a pre-change baseline: identical entry listings for all seven jars, identical generated POMs for :app, :setup and :bridge, identical publish task set, and identical test results (21 classes, 56 tests). The only dependency-graph difference is the jacocoAgent/jacocoAnt tooling configurations in the three modules that gained Jacoco; they reach no compile or runtime class path. -Xlint:deprecation now surfaces five pre-existing warnings for the deprecated Aves GsonFileHandler and AnvilLoader(Path). They are left as warnings on purpose - replacing them is separate work. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QtbnMbAj6m2q3vrDYFizDr
TheMeinerLP
force-pushed
the
build/buildsrc-conventions
branch
from
August 27, 2026 20:03
c9a0860 to
00dfaed
Compare
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
1 participant
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.
Warum
Die Build-Logik war über die Modul-Buildfiles hinweg kopiert statt geteilt:
java { toolchain { …25 } }useJUnitPlatform,-Dminestom.inside-test=true)9.6.1hartcodiertapply false):common+:setup:apphatte 15 Testklassen, aber keinen Coverage-Report, weil Jacoco dort nie angewendet wurde.Was
Zwei precompiled script plugins in
buildSrc:titan.java-conventions— Toolchain 25, javac-Optionen (--release 25, UTF-8,-Xlint:deprecation,unchecked), JUnit-Platform mitminestom.inside-test, Jacoco mit XML-Report antestgekoppelttitan.publish-conventions— diemaven-Publication mit Koordinaten, POM-Metadaten und dem OneLiteFeather-RepositoryIn den Modulen bleibt nur, was sich tatsächlich unterscheidet —
artifactId, POM-name/descriptionund die publizierten Artefakte:Unterm Strich: −207 / +151 Zeilen, 245 Zeilen dupliziertes Modul-Boilerplate ersetzt durch 109 Zeilen geteilte Conventions.
Damit erfüllt Titan OLF-L1-01 aus dem OLF-Minestom-Project-Standard und zieht mit Cygnus'
cygnus.java-conventionsgleich.Verifikation — keine Änderung am Build-Output
Gegen einen Baseline-Build von
mainvor der Änderung geprüft:api,common,bridge,app-titan.jar,setup-titan.jar, beide-unshaded:app,:setup,:bridgepublishMavenPublicationToOneLiteFeatherRepositoryRepository)jacocoAgent/jacocoAnt-Konfigurationen in:app,:api,:bridge— reine Tooling-Konfigurationen, die auf keinem Compile- oder Runtime-Classpath landen (bestätigt durch die identischen Jars)Nebeneffekt
-Xlint:deprecationlegt fünf bereits vorhandene Warnungen offen:Bewusst als Warnung stehen gelassen — der Wechsel auf
ModernGsonFileHandlerist eigene Arbeit (Phase 3 des Standards).Nicht Teil dieses PRs
gradle.propertiessamtsubstringBefore('#')-Hack. Der Umzug nachbuild.gradle.kts(wie in Cygnus) berührtrelease-please-config.jsonund gehört in einen eigenen PR.shadowJar-Konfiguration bleibt pro Modul::appsetzt Signatur-/module-info-Excludes undDuplicatesStrategy.EXCLUDE,:setupnicht. Vereinheitlichen würde den Output verändern und ist damit kein reines Refactoring.subprojects {}-Block des Root-Builds.🤖 Generated with Claude Code
https://claude.ai/code/session_01QtbnMbAj6m2q3vrDYFizDr