Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Gradle migration follow-ups (post-#326)

オープン
  • 何か問題がありますか？
#337 コメント 2 件 リアクション 2 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
28/100
issue の種類
リファクタリング
明瞭さ
おおむね明確
活発さ
静か
技術スタック
java, kotlin
領域
build-system, developer-experience, tooling

調査の方向性

This is an umbrella follow-up to PR #326, not a single change. Start from the Gradle wrapper (currently 8.14.1), verifyDistributionPlacement (Task.project-at-execution deprecation), the Groovy build scripts, and the version catalog. Pick one checkbox only: Gradle 9 bump, Kotlin DSL, .gitignore header cleanup, BOM alignment (#389), or a named CVE bump. Done means that one item is complete with the existing byte-identical parity harness still green; do not treat the whole list as one first issue.

索引モデルが issue の本文から書いたものです。

説明

licensing

PR #326 migrated the build from Ant to Gradle with output verified byte-identical. To keep that PR reviewable and parity-checkable, several improvements were deliberately deferred. This issue tracks them. Parent: #52.

Build tooling
  • Try Gradle 9. The wrapper ships on 8.14.1. Confirm the build runs clean under Gradle 9 and bump when it does. One known item to clear first: a Task.project-at-execution-time deprecation in verifyDistributionPlacement that Gradle 9 warns on and Gradle 10 removes. (raised by @jbeckers in #326)
  • Consider the Kotlin DSL for the build scripts. Currently Groovy; Kotlin is Gradle's official recommendation. (raised in #326, agreed as a follow-up)
  • Clean up stale .gitignore headers. ~111 inert commented section headers (# /client/src/com/...) date to the original 2017 .gitignore and still reference the pre-move layout. Update to src/main/java or drop them. (raised by @jbeckers in #326)
Dependencies
  • Align multi-artifact dependency families with BOMs. The catalog versions every artifact of a family independently, so a bot can bump part of a set and leave it incoherent with nothing to catch it. That is #389: log4j-api stayed at 2.25.3 while log4j-core and log4j-1.2-api moved to 2.25.4, and the server would not boot. Import platform(libs.<x>.bom) for log4j, jackson, netty, jetty, and the AWS SDK. Constrains versions only, pulls nothing transitively, flat explicit list stays intact.
  • Normalize to transitive resolution, one library at a time. The migration intentionally pins a non-transitive, audited set matching the historical vendored jars. Enable transitivity per library during routine version bumps, diff against the flat list, reconcile, re-verify with the parity harness. Flat lists remain better for scanning accuracy, so this is a slow bridge with no deadline. (objection from @jbeckers in the comments)
  • CVE burn-down. An initial dependency-check baseline flagged ~54 distinct CVEs across ~46 jars. Start with the one-line, parity-checkable bumps (netty, jackson-databind, pdfbox), then the harder ones: Jetty 9.4.57 (EOL line), MyBatis (#320), Derby, iText -> OpenPDF (#289), commons-httpclient -> httpclient5. See also #304.
  • Adopt byte-identical repackaged jars from Maven Central. 13 vendored jars are content-identical to Central artifacts (the HAPI 2.3 set, jtds, sqlite-jdbc, rsyntaxtextarea, autocomplete) and can be sourced from Central. The 3 genuine forks (javaparser 1.0.8, zip4j 1.3.3, not-going-to-be-commons-ssl) stay vendored.
主要言語
Java
スター
227
フォーク
81
平均マージ
2日 16時間
マージ済み PR（30日）
12

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

OpenIntegrationEngine/engine のほかの issue

OpenIntegrationEngine/engine の issue をすべて見る

似ている issue

Java の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。