Après la mise à jour de Spring Boot 2.5.0, il génère le fichier myProgram-0.0.1-Plain.jar aux côtés du myProgram-0.0.1.jar habituel. Puis-je interdire Gradle pour générer le fichier *. Plain.jar ? J'utilise Gradle 7.0.2.
Ce que j'obtiens:
plugins {
id 'org.springframework.boot' version '2.5.0'
id 'io.spring.dependency-management' version '1.0.11.RELEASE'
id 'java'
}
group = 'com.example'
version = '0.0.1-SNAPSHOT'
sourceCompatibility = '11'
repositories {
mavenCentral()
}
dependencies {
implementation 'org.springframework.boot:spring-boot-starter'
testImplementation 'org.springframework.boot:spring-boot-starter-test'
}
test {
useJUnitPlatform()
}
5 Réponses :
Ce fut un changement dans Spring Boot 2.5.0.
Comme @ ThomasklLeger l'a souligné: vous pouvez le définir dans la configuration build.gradle .
build.gradle
tasks.getByName<Jar>("jar") {
enabled = false
}
Merci pour l'exemple de Kotlin. tasks.jar {activé = false} a fonctionné pour moi; Je ne sais pas s'il y a une différence.
Avec jar {activé = false} , il ne génère aucun jar (pas seulement avec plain postfix). Comment cela peut-il être une réponse acceptée?
@Srzhio Étrangement, cela ne désactive que le pot .Plain, et non le pot complet. docs .spring.io / spring-boot / docs / current / gradle-plugin / arbitre nce /…
@Innokenty, oui, c'est ce que la documentation indique, mais seulement bootjar.enabled = true; jar.enabled = false a fonctionné pour moi
Je viens de tester avec un tout nouveau projet de start.spring.io avec Spring Boot 2.6.5 et l'ajout de jar.enabled = false et je peux confirmer que le pot de démarrage est toujours généré lors de l'exécution . / gradlew build . La pièce bootjar.enabled = true n'est pas requise.
Essayez Utiliser le paramètre Suivre:
private void classifyJarTask(Project project) {
project.getTasks().named(JavaPlugin.JAR_TASK_NAME, Jar.class)
.configure((task) -> task.getArchiveClassifier().convention("plain"));
}
Voir:
J'en avais besoin parce que j'ai la bibliothèque partagée sur d'autres projets et j'utilise le plugin Spring Boot là aussi. Je ne peux donc pas configurer BOOTJAR activé à False.
Commentant la ligne de version // version = "0.0.1-snapshot" et en utilisant Just war {archiveclassifier.set ("")} dans le fichier build.gradle.kts a fonctionné pour moi (voulait renommer le fichier de guerre dans mon cas). Il a changé le nom du fichier de guerre de Demo-0.0.1-Snapshot-Plain.War à Demo.War
Cette configuration Gradle produira MyProgram-0.0.1.jar au lieu de MyProgram-0.0.1-pain.jar
dans votre build. gradle.kts
// Build executable jar
tasks.jar {
enabled = true
// Remove `plain` postfix from jar file name
archiveClassifier.set("")
}
@OCase vous m'avez enregistré ici ... wow ... je viens de migrer une application entière avec des builds Docker automatisés pour utiliser les pots (bot-boot) et je ne pouvais pas m'attendre à 2 pots lol
Après avoir utilisé cela, je n'ai pas manifesté :( Aucun attribut principal manifeste, dans Build / Libs / Microadmin-Service-1.0.0-Release.jar ... donc, ma solution pour contourner cela était d'exécuter " gradle bootjar "
Au lieu d'utiliser la tâche build gradle, vous pouvez utiliser bootjar . Qui ne fera que construire le pot de démarrage.
Gardez à l'esprit que bootjar n'exécutera pas vos tests avant la construction.
Solution testée. J'étais confronté au même problème: il suffit d'ajouter ci-dessous dans votre gradle
jar{
archiveClassifier=''
enabled = false
}
Il est utile de lire La documentation de démarrage de Spring : Vous pouvez le désactiver si vous n'en avez pas besoin.
@ Thomaskläger Oui, merci. Je ne m'attendais pas à ce changement de rupture. Le serveur CI s'attendait à un seul fichier dans LiBS.
Reportez-vous Réponse
Commentant la ligne de version
// version = "0.0.1-snapshot"et utilisantwar {archiveClassifier.set ("")}dans build.gradle.kts le fichier a fonctionné Pour moi (voulait renommer le fichier de guerre dans mon cas). Il a changé le nom du fichier de guerre de Demo-0.0.1-Snapshot-Plain.War à Demo.WarMême problème ici. Le deuxième jair s'est écrasé ou construit des pipelines.