Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

Support Spring Boot apps with no explicit version config

Geschlossen
  • Stimmt etwas nicht?
#155 3 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
25/100
Issue-Typ
Bug
Klarheit
Muss geklärt werden
Aktivitätsstatus
Veraltet
Tech-Stack
java, kotlin, spring-boot
Bereich
build-system

Rechercherichtung

Beginne mit dem Kotlin rewriteRun-Test im Issue und untersuche die vorhandenen recipes, die die java.version-Eigenschaft aktualisieren. Ermittle, wie Spring Boot parent defaults zusammen mit anderer Java-Versionskonfiguration behandelt werden sollen, und füge Abdeckung für das gewählte Verhalten hinzu. Als erledigt gilt die Aufgabe, wenn der bereitgestellte Test besteht, ohne bestehende Migrationsfälle zu beeinträchtigen.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

design-partner-3 enhancement

test case:

    @Test
    fun `adds java version property if not present if spring-like parent`() = rewriteRun(
        pomXml("""
            <?xml version="1.0" encoding="UTF-8"?>
            <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
              <modelVersion>4.0.0</modelVersion>
              <groupId>org.sample</groupId>
              <artifactId>sample</artifactId>
              <version>1.0.0</version>
              
              <parent>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-starter-parent</artifactId>
                <version>2.7.0</version>
              </parent>
              
            </project>
        """.trimIndent(),
            """
            <?xml version="1.0" encoding="UTF-8"?>
            <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
              <modelVersion>4.0.0</modelVersion>
              <groupId>org.sample</groupId>
              <artifactId>sample</artifactId>
              <version>1.0.0</version>
              
              <parent>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-starter-parent</artifactId>
                <version>2.7.0</version>
              </parent>
              <properties>
                <java.version>11</java.version>
              </properties>
              
            </project>
        """.trimIndent()
        ) // fails with no change
    )

Spring Boot declares a java.version property, pre-wired into the maven-compiler-plugin config. This is a convenient, common pattern to manage a project's Java version, and our recipes support updating that property if present.

But, because Spring Boot provides a default value (1.8) for java.version, it's feasible for a Spring Boot app to have no explicit configuration for its Java version in its pom.xml. And in that case, the upgrade recipe will do everything but actually update the build's Java version. The test case above shows this.

The tricky part here is deciding how generic the solution should be -- eg:

  • do we just check for the "hardcoded" spring-boot-starter-parent parent, or identify arbitrary (non-project) parents which declare java.version
  • should we validate that project pom isn't already managing its java version a different way (ie no explicit maven-compiler-plugin config)
  • should we enforce an opinion that projects with spring-like parents should only use the java.version property to manage the Java version
Vorherrschende Sprache
Java
Sterne
160
Forks
133
Ø Merge
4 Std. 52 Min.
Gemergte PRs (30 T.)
105

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus openrewrite/rewrite-migrate-java

Alle Issues in openrewrite/rewrite-migrate-java

Ähnliche Issues

Weitere Issues zu Java

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.