L'outil de construction populaire d'IntelliJ IDEA - Gradle

IntelliJ IDEA est un environnement intégré pour le développement du langage de programmation Java. IntelliJ est reconnu comme le meilleur outil de développement Java de l'industrie, en particulier dans l'assistant de code intelligent, l'invite de code automatique, le refactoring, le support JavaEE, divers outils de version (git, svn, etc.), JUnit, l'intégration CVS, l'analyse de code, le des fonctions telles que la conception de l'interface graphique peuvent être qualifiées d'extraordinaires.

De nos jours, les outils de construction sont une partie importante de tous les projets, et IntelliJ IDEA a été intégré à la plupart des outils de construction.L'outil de construction populaire actuel est Gradle. Dans cet article, nous décrivons brièvement l'historique de son intégration avec IntelliJ IDEA et le processus de délégation mis en œuvre au sein de l'IDE.

Téléchargement de la version officielle d'IntelliJ IDEA v2023.1

point de départ

IntelliJ IDEA est sur le marché depuis plus longtemps que tout autre outil de build et propose son système de build natif depuis de nombreuses années avec un grand succès. Le système de construction IntelliJ IDEA est toujours le meilleur choix pour des tâches telles que la compilation, l'exécution de tests et le conditionnement dans des fichiers JAR.

Les développeurs sont souvent principalement concernés par la compilation et l'exécution des tests. Un cycle de rétroaction rapide pour le processus de construction est donc essentiel, tandis que nous nous spécialisons dans l'exécution des tests JUnit et TestNG et la compilation incrémentielle.

Avant Gradle

Maven est sorti avec d'excellentes capacités de gestion des dépendances de projet, et nous avons tiré parti de sa structure de projet et délégué le téléchargement et la résolution des dépendances à Maven (mais laissé le processus de construction à IntelliJ IDEA).

Nous avons pu répliquer le processus de construction de Maven dans le système de construction IntelliJ IDEA. Basé sur le modèle de projet Maven, IntelliJ IDEA peut construire des projets avec un minimum d'étapes supplémentaires. Dans le même temps, nous avons développé un mécanisme pour récupérer efficacement les informations de traitement des ressources, couvrant la génération de fichiers MANIFEST.mf à partir de pom.xml et améliorant encore le processus de construction.

Nous appliquons ensuite les résultats du processus de construction au processus natif qui exécute les tests.

Grâce à cette amélioration, nous avons pu couvrir tous les scénarios nécessaires pour construire avec succès un projet Maven avec IntelliJ IDEA.

Continuez à utiliser cette configuration pour les projets Maven : récupérez les informations nécessaires auprès de Maven, créez et démarrez des projets à l'aide des mécanismes natifs d' IntelliJ IDEA , même pour des outils populaires tels que Spring Boot et Micronaut.

Intégrer Gradle

Lorsque Gradle a été lancé sur le marché, il a donné aux utilisateurs la possibilité de mieux personnaliser le processus de construction et d'y ajouter plus de fonctionnalités.

Lorsque la décision a été prise de commencer à faire quelque chose de similaire à Maven, cela signifiait laisser Gradle gérer les dépendances et récupérer les informations nécessaires, tandis qu'IntelliJ IDEA compilerait le code, exécuterait les tests et construirait le projet.

Cependant, le modèle de projet Gradle semble un peu trop flexible, vous pouvez utiliser différents ensembles de sources ou langages dans le script de construction, tels que Groovy, Scala ou Kotlin. Alternativement, le code impératif peut être écrit dans des scripts de construction pour fournir des instructions directes au système de construction pour le comportement et les paramètres souhaités.

Par exemple, la base de données peut être démarrée avant l'exécution ou avant l'exécution du test. De plus, par rapport à Maven, qui contient une configuration statique, les scripts de construction Gradle permettent l'exécution de code arbitraire lors du traitement des ressources. Il est difficile de reproduire de telles configurations avec IntelliJ IDEA.  caractéristiques .

Clairement excellent pour les opérations standard, mais les opérations personnalisées, telles que la gestion des ressources et d'autres tâches personnalisées, étaient plutôt difficiles à contrôler, à maintenir et, surtout, à répliquer dans le système de construction IntelliJ IDEA.

Par conséquent, nous avons décidé de déléguer l'exécution du test à Gradle :

Lorsque vous exécutez des tests, la tâche de test Gradle est exécutée avec d'autres tâches faisant partie du cycle de construction Gradle, comme suit :

De plus, IntelliJ IDEA fournit également des fonctionnalités supplémentaires, par exemple, les tests que vous devez exécuter peuvent être distribués dans différents ensembles de sources. Les tests d'intégration se trouvent dans un ensemble source et les tests fonctionnels dans un autre.

IntelliJ IDEA peut déterminer correctement la tâche de test et son emplacement pour un fichier de test spécifique, garantissant ainsi que les tests pertinents sont exécutés efficacement.

De plus, IntelliJ IDEA fournit également des informations sur le niveau d'exécution des tests - méthode, classe ou package, par exemple, Gradle exécute tous les tests dans l'ensemble source par défaut.

Mais IntelliJ IDEA applique le mode filtre et affiche un message dans la fenêtre de l'outil Exécuter vous indiquant exactement où le test a été exécuté :

Dans l'ensemble, le délégué de test de Gradle est assez réussi.

La prochaine étape naturelle consiste à déléguer également les opérations de construction et d'exécution à Gradle, et finalement la délégation devient le choix par défaut.

Désormais, lorsque l' action Run est utilisée dans l'application  , elle est utilisée dans le contexte Gradle et effectuée de manière dynamique.

Semblable au plugin d'application Gradle existant, nous créons une tâche de type JavaExec qui exécute la classe principale, ce qui garantit une exactitude maximale de la configuration d'exécution de l'application.

Lorsque Build est déclenché en mode délégué, IntelliJ IDEA génère une liste de commandes qui doivent être exécutées dans Gradle en fonction des modules modifiés dans le projet. Vous pouvez afficher ces informations dans BuildOutput :

IntelliJ IDEA peut également détecter les fichiers modifiés dans différents modules et ne construire que les parties modifiées.

Actuellement, vous avez le choix entre deux modes de délégation : Gradle et IntelliJ IDEA.

• Gradle : Bien que le processus soit délégué à Gradle, il est légèrement plus lent que notre système de construction natif et a une petite surcharge. Parfois, en mode délégué, le démon Gradle doit être réexécuté.
  De plus, Gradle préserve ses processus de cycle de vie, réexécute les modèles Gradle et vérifie les scripts de construction et leur système de fichiers même s'il existe du code compilé par IntelliJ IDEA.
• IntelliJ IDEA : Si vous n'avez pas de paramètres compliqués dans votre projet Gradle, vous pouvez utiliser IntelliJ IDEA pour accélérer le processus de construction.

Notez également que le traitement des annotations est pris en charge dans le flux de compilation, mais lorsque le code est compilé par IntelliJ IDEA  , certains cas extrêmes sont difficiles à gérer, comme le cas où le processeur d'annotations est défini dans un sous-projet Gradle.

C'est à ce stade que nous en sommes actuellement, essayant toujours d'exécuter les configurations d'exécution Spring et Micronaut en mode délégué et continuant d'améliorer le processus de délégation Gradle dans l'IDE.