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

Support Spring Boot apps with no explicit version config

Fermée
  • Quelque chose ne va pas ?
#155 3 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
25/100
Type d'issue
Bug
Clarté
À clarifier
Activité
À l'abandon
Stack technique
java, kotlin, spring-boot
Domaine
build-system

Piste de recherche

Commencez par le test Kotlin rewriteRun de l’issue et examinez les recipes existantes qui mettent à jour la propriété java.version. Déterminez comment les valeurs par défaut de Spring Boot parent doivent être gérées avec les autres configurations de version de Java, puis ajoutez une couverture pour le comportement choisi. Le travail est terminé lorsque le test fourni réussit sans casser les cas de migration existants.

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

Description

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
Langage dominant
Java
Étoiles
160
Forks
133
Merge moyen
4 h 52 min
PR mergées (30 j)
105

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 openrewrite/rewrite-migrate-java

Toutes les issues de openrewrite/rewrite-migrate-java

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.