Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

Gradle migration follow-ups (post-#326)

Ouverte
  • Quelque chose ne va pas ?
#337 2 commentaires 2 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 2 jours

Personne n'a encore pris cette issue.

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
28/100
Type d'issue
Refactorisation
Clarté
Plutôt claire
Activité
Calme
Stack technique
java, kotlin
Domaine
build-system, developer-experience, tooling

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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.
Langage dominant
Java
Étoiles
227
Forks
81
Merge moyen
3 j 6 h
PR mergées (30 j)
15

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de OpenIntegrationEngine/engine

Toutes les issues de OpenIntegrationEngine/engine

Issues similaires

Plus d'issues Java

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.