J'utilise le plugin Gradle spring-boot
et je dois sélectionner un profil actif à ressort pour le test.
Comment passer de la propriété système spring.profiles.active
à la tâche du plugin bootRun
?
Ce qui a déjà échoué:
task bootRunLocal {
systemProperty "spring.profiles.active", "local"
System.setProperty("spring.profiles.active", "local")
tasks.bootRun.execute() // I suspect that this task is executed in a separate JVM
}
et un peu de magie en ligne de commande échoue également:
./gradle -Dspring.profiles.active=local bootRun
Quelqu'un pourrait-il bien vouloir m'aider à résoudre mes problèmes?
Mise à jour à partir des réponses et commentaires:
Je peux configurer le systemProperty et le transmettre au conteneur de ressort en faisant:
run {
systemProperty "spring.profiles.active", "local"
}
Toutefois, lorsque je le fais, le profil local est défini pour les tâches bootRun
et bootRunLocal
. J'ai besoin d'un moyen de définir cette propriété pour la tâche bootRunLocal
et d'appeler la tâche booRun
à partir de bootRunLocal
.
Cela peut sembler très simple, mais je viens en paix du monde structuré de Maven.
task local {
run { systemProperty "spring.profiles.active", "local" }
}
bootRun.mustRunAfter local
Puis lancez la commande gradle en tant que:
gradle bootRun local
Je sais que je suis en retard ici ... mais j'ai récemment été confronté à ce problème précis. J'essayais de lancer bootRun avec spring.profiles.active et spring.config.location définis en tant que propriétés système sur la ligne de commande.
Donc, pour que votre "magie" de ligne de commande fonctionne, ajoutez-la simplement à votre build.gradle
bootRun {
systemProperties System.properties
}
Puis en cours d'exécution depuis la ligne de commande ...
gradle -Dspring.profiles.active=local bootRun
Définira local comme profil actif, sans avoir à définir une tâche distincte simplement pour ajouter la variable env.
Il n'y a pas de moyen générique de transmettre les propriétés du système à une tâche. En un mot, il est uniquement pris en charge pour les tâches qui utilisent une machine virtuelle Java distincte.
La tâche bootRunLocal
(telle que définie ci-dessus) ne sera pas exécutée dans une machine virtuelle Java distincte, et l'appel de execute()
sur une tâche n'est pas pris en charge (et doit avoir lieu dans la phase d'exécution dans tous les cas). Les tests, en revanche, sont toujours exécutés dans une machine virtuelle Java distincte (s’ils sont exécutés par une tâche Test
). Pour définir les propriétés système pour l'exécution du test, vous devez configurer la ou les tâches Test
correspondantes. Par exemple:
test {
systemProperty "spring.profiles.active", "local"
}
Pour plus d'informations, voir Test
dans Référence de langage de construction de Gradle .
Pour le grade 2.14 ci-dessous, l'exemple fonctionne. J'ai ajouté comme ci-dessous.
Lorsque System.properties ['spring.profiles.active'] a la valeur null, le profil par défaut est défini.
bootRun {
systemProperty 'spring.profiles.active', System.properties['spring.profiles.active']
}
exemple de ligne de commande
gradle bootRun -Dspring.profiles.active=dev
Juste pour référence si quelqu'un aura ce problème:
Vlad réponse n'a pas fonctionné pour moi mais celui-ci fonctionne très bien avec la version 2.4,
task local <<{
bootRun { systemProperty "spring.profiles.active", "local" }
}
local.finalizedBy bootRun
alors gradle local
Répondre à la demande exacte d'OP ici ...
Comment passer de la propriété système spring.profiles.active à la tâche du plug-in bootRun?
Et en supposant que "passer", l'OP signifiait "passer de la ligne de commande" ou "passer de IDE invocation" ... Voilà comment j'aime le faire.
Ajoutez ceci à build.gradle:
/**
* Task from spring-boot-gradle-plugin, configured for easier development
*/
bootRun {
/* Lets you pick Spring Boot profile by system properties, e.g. gradle bootRun -Dspring.profiles.active=dev */
systemProperties = System.properties
}
Ensuite, lorsque vous l'appelez, utilisez l'indicateur Java bien connu pour définir une propriété système.
gradle bootRun -Dspring.profiles.active=local
Il y a un avantage principal à s'en tenir aux propriétés système, par rapport à l'option de variables d'environnement (SPRING_PROFILES_ACTIVE=local gradle bootRun
) ... et à la portabilité facile entre Linux/OS X (bash, etc.) et Windows (cmd.exe de toute façon).
J'ai appris cela de cet article de blog .
(MISE À JOUR: Ah, j'avais malheureusement manqué la réponse de @ Erich avec la même recommandation. Oups! Je laisse ma réponse, à cause des détails supplémentaires sur la portabilité, etc.)
Vous pouvez créer une nouvelle tâche (dans le cas discuté avec le nom bootRunLocal
), qui étendrait org.springframework.boot.gradle.run.BootRunTask
et définira les propriétés avant l’exécution de la tâche. Vous pouvez créer une telle tâche avec le code suivant:
task bootRunLocal(type: org.springframework.boot.gradle.run.BootRunTask) {
doFirst() {
main = project.mainClassName
classpath = sourceSets.main.runtimeClasspath
systemProperty "spring.profiles.active", "local"
}
}
Vous trouverez plus de détails ici: https://karolkalinski.github.io/gradle-task-that-runs-spring-boot-aplication-with-profile-activated/
Selon la documentation de spring-boot-gradle-plugin , vous devriez pouvoir passer des arguments comme celui-ci.
./gradlew bootRun --args='--spring.profiles.active=dev'
On dirait que c'est une nouvelle fonctionnalité depuis 4.9. Je l'ai utilisé dans mon projet et cela a fonctionné hors de la boîte.
Cela marche:
SPRING_PROFILES_ACTIVE = production ./gradlew app-service: bootRun
A partir de SpringBoot 2.0.0-M5 setSystemProperties()
n'est plus une méthode de la tâche bootRun . Le fichier build.gradle doit être mis à jour pour
bootRun {
execSpec {
// System.properties["spring.profiles.active"]
systemProperties System.properties
}
}
C'est comme la tâche d'exécution de springBoot utilise org.gradle.process.JavaExecSpec
Cela fonctionne pour moi en utilisant Gradle 4.2
Une autre manière qui ne nécessite aucune prise en charge de la tâche de gradeau: Définissez la variable Java_TOOL_OPTIONS environment:
Java_TOOL_OPTIONS='-Dfoo=bar' gradle ...
Ou si la variable peut déjà contenir quelque chose d'utile:
Java_TOOL_OPTIONS="$Java_TOOL_OPTIONS -Dfoo=bar" gradle ...
// defualt value
def profiles = 'dev'
bootRun {
args = ["--spring.profiles.active=" + profiles]
}
Ensuite, vous pouvez simplement choisir une version spécifique lors du démarrage d’une tâche
./gradlew bootRun -P dev
"dev" va avoir lieu "prod"
avec la commande run, vous pouvez ajouter au fichier de construction run { systemProperties = System.properties }
et commencer par gradle run -Dspring.profiles.active=local