No Gradle toolchain is declared, so the build silently uses whatever JAVA_HOME provides
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 1-2 días
- Aptitud para principiantes
- 48/100
- Tipo de issue
- Error
- Claridad
- Bastante claro
- Estado de actividad
- Tranquilo
- Área
- build-system, tooling
Línea de trabajo
Read maddi-kotlin-k2/build.gradle.kts, which already documents using the daemon JDK instead of a provisioned toolchain because Kotlin 2.4 targets JVM 25 while development uses JDK 26. Add a Gradle toolchain that still allows that split so local and CI builds match. Cross-check docs/landing-surface-checklist.md §3. Done when ./gradlew build uses a declared toolchain without breaking the openjdk/k2 compiler path.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
There is no Gradle toolchain declaration anywhere, so the build compiles against whatever
JAVA_HOME happens to be. This is the same class of latent portability bug as the missing daemon
heap, which made git clone && ./gradlew build fail on any machine without a user-level
~/.gradle/gradle.properties — it passed locally only because that file supplied one, and CI was
the first environment honest enough not to have it.
Declaring a toolchain would make CI and local builds agree by construction rather than by
convention.
The complication, which is why this is not a one-liner. The openjdk front end reaches into
jdk.compiler internals, and maddi-kotlin-k2/build.gradle.kts already notes that it deliberately
uses the daemon JDK rather than a provisioned toolchain, because Kotlin 2.4 caps its target at JVM
25 while development happens on JDK 26. Any toolchain declaration has to accommodate that split.
Recorded in docs/landing-surface-checklist.md §3.
- Lenguaje dominante
- Java
- Estrellas
- 1
- Forks
- 1
- Merge medio
- 1 h 58 min
- PR fusionados (30 d)
- 5
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Tiene una plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de CodeLaser/maddi
-
build/ci good first issue
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
Los mantenedores suelen responder en 1 día
-
Dificultad 4/5 3-5 días Aptitud para principiantes 48/100
Los mantenedores suelen responder en 1 día
-
C# printer: a self-bounded interface's wildcard interface and companion class share a name (CS0102)Abierto
Dificultad 3/5 1-2 días Aptitud para principiantes 64/100
CodeLaser/maddi#160 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
bug
Dificultad 3/5 1-2 días Aptitud para principiantes 68/100
Los mantenedores suelen responder en 1 día
-
bug front-end:javac
Dificultad 4/5 3-5 días Aptitud para principiantes 42/100
CodeLaser/maddi#145 · 1 comentario ·
Los mantenedores suelen responder en 1 día
Todos los issues de CodeLaser/maddi
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
QuiltMC/update-quilt-meta#28 ·
-
area/kotlin
Dificultad 2/5 1-3 horas Aptitud para principiantes 84/100
Los mantenedores suelen responder en 1 día
-
Tell us about your use cases!Abierto
Dificultad 1/5 Menos de una hora Aptitud para principiantes 75/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
Los mantenedores suelen responder en 1 día
-
Large page[number] overflows the computed offset and returns the wrong pagePosiblemente ocupada @auraseb la tomó hoy. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
Los mantenedores suelen responder en 1 día