JetBrains annonce que Amper 0.11.0 est disponible et devient Kotlin Toolchain, un point d'entrée unifié vers Kotlin, permettant de développer des applications JVM, Android, iOS, multiplateformesKotlin est un langage de programmation multiplateforme, à typage statique, polyvalent et de haut niveau, doté d’une inférence de types. Kotlin est conçu pour interagir pleinement avec Java, et la version pour la machine virtuelle Java (JVM) de la bibliothèque standard de Kotlin s’appuie sur la bibliothèque de classes Java. Cependant, l'inférence de types permet une syntaxe plus concise. Kotlin cible principalement la JVM, mais se compile également en JavaScript (par exemple, pour les applications web front-end utilisant React) ou en code natif via LLVM (par exemple, pour les applications iOS natives partageant une logique métier avec des applications Android). JetBrains prend en charge les coûts de développement du langage, tandis que la Fondation Kotlin protège la marque Kotlin.
JetBrains (anciennement IntelliJ Software) est une société à responsabilité limitée internationale spécialisée dans le développement de logiciels, qui conçoit des outils destinés aux développeurs et aux chefs de projet. JetBrains propose divers environnements de développement intégrés (EDI), tels que IntelliJ IDEA, PyCharm, Rider, WebStorm et CLion. Elle a également créé en 2011 le langage de programmation Kotlin, qui peut s'exécuter dans une machine virtuelle Java (JVM).
JetBrains annonce que Amper 0.11.0 est disponible, et vous remarquerez immédiatement un changement dans l’image de marque du produit. Si vous avez manqué le discours d’ouverture de la KotlinConf, voici l’essentiel : Amper est devenu Kotlin Toolchain (chaîne d’outils Kotlin) et est désormais en version Alpha ! Cette version concrétise cette transition, tout en offrant la possibilité de publier des bibliothèques JVM, de nouvelles API de développement de plugins et plusieurs améliorations de l’expérience développeur.
Amper est désormais la chaîne d’outils Kotlin
Lorsque JetBrains a lancé Amper, l’objectif était d’expérimenter une expérience de build cohérente et déclarative. Au fur et à mesure que le projet évoluait, il est apparu clairement que l’écosystème n’avait pas seulement besoin d’un nouvel outil de build, mais d’un point d’entrée unifié vers l’ensemble de Kotlin.
La chaîne d’outils Kotlin est ce point d’entrée cohérent. Elle fournit une commande unique, kotlin, qui vous permet de créer un projet, de le compiler, de l’exécuter et de le tester, ainsi que de le configurer pour le packaging et la publication. À l’avenir, elle vous permettra même de formater votre code, de générer de la documentation et bien plus encore. Plus besoin de choisir un outil de compilation dès le départ ; plus besoin de configurer des plugins complexes avant de pouvoir écrire votre première ligne de code.
JetBrains commente : « Bien sûr, nous ne sommes pas partis de zéro. Tout ce que nous avions développé au sein d’Amper a été transféré vers la chaîne d’outils Kotlin, ce qui a permis au projet de passer directement au stade Alpha ! Ce statut signifie que JetBrains s’engage à le prendre en charge ; nous serions donc ravis que vous l’essayiez et que vous nous fassiez part de vos commentaires. »
Si vous utilisiez déjà Amper, ce changement majeur a plusieurs implications dont vous devez prendre connaissance :
- Les scripts de wrapper amper et amper.bat doivent être remplacés par les nouveaux wrappers kotlin et kotlin.bat.
- Dans IntelliJ IDEA, le plugin EDI « Kotlin Toolchain » doit être installé à la place du plugin EDI Amper, que vous pouvez désinstaller en toute sécurité.
Installation globale
Les scripts d’encapsulation intégrés à votre projet sont parfaits pour offrir une expérience « cloner et compiler » sans aucune exigence d’installation, mais ils ne conviennent pas à tous les cas d’utilisation. Avec cette nouvelle version, vous pouvez désormais installer la CLI Kotlin de manière globale (en dehors d’un projet) et l’utiliser partout à la place de ./kotlin. Vous pouvez l’installer dès maintenant via SDKMAN! de la manière suivante :
| Code : | Sélectionner tout |
sdk install kotlintoolchain
Remarque : vous n’êtes pas obligé d’utiliser SDKMAN!. Consultez la documentation pour découvrir d’autres options d’installation.
Cela améliore l’expérience à plusieurs égards :
- Le lancement des commandes Kotlin à partir de répertoires imbriqués au sein de votre projet est plus pratique.
- Vous pouvez utiliser des commandes indépendantes du projet depuis n’importe quel répertoire (comme kotlin tool jaeger ou kotlin clean-shared-caches).
- La création de nouveaux projets avec la commande init est plus intuitive (plus besoin de télécharger manuellement un wrapper ni de le copier depuis un autre projet).
L’utilisation de la commande globale kotlin ne signifie toutefois pas que vous devrez harmoniser la version de votre chaîne d’outils Kotlin dans tous vos projets. La commande kotlin détecte automatiquement le script wrapper de votre projet et exécute la version correspondante de la chaîne d’outils Kotlin.
Publication
La fonctionnalité de publication de bibliothèques est enfin disponible en préversion ! Vous pouvez désormais publier vos bibliothèques JVM dans des référentiels Maven, y compris Maven Central.
Remarque : les bibliothèques Kotlin Multiplatform ne peuvent pas encore être publiées.
Référentiels Maven classiques
Pour publier vers un référentiel Maven autre que Maven Central, utilisez la configuration suivante dans votre fichier module.yaml :
| Code : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 | product: jvm/lib
repositories:
- id: myMavenRepoId
url: https://maven.pkg.github.com/my-org/my-maven-repo
publish: true
credentials:
file: creds.properties # a properties file containing your credentials
usernameKey: maven.username # the name of the property containing the username
passwordKey: maven.password # the name of the property containing the password
settings:
publishing:
enabled: true
group: com.example
artifactId: greeter # optional, defaults to the module name
version: 1.0.0 |
Fournissez le fichier d’identifiants référencé dans la configuration du référentiel, par exemple ce fichier creds.properties :
| Code : | Sélectionner tout |
1 2 | maven.username=john.doe maven.password=MyVerySecurePassword123 |
Vous pouvez ensuite référencer le référentiel par son ID lorsque vous exécutez la commande de publication :
| Code : | Sélectionner tout |
kotlin publish myMavenRepoId
Cette commande publie tous les modules dont la publication est activée et qui ont déclaré un référentiel portant l’ID myMavenRepoId.
Maven Central
La publication sur Maven Central est réputée pour être un processus fastidieux impliquant de nombreux éléments : fichiers source et JAR Javadoc, signatures PGP, métadonnées POM, sommes de contrôle, etc. La dernière version de la chaîne d’outils Kotlin s’occupe de tout cela pour vous : vous déclarez ce que vous souhaitez publier, elle se charge du reste.
Vous aurez d’abord besoin d’un compte, d’un espace de noms et d’un jeton utilisateur sur le portail Maven Central Publisher, ainsi que d’une clé de signature PGP. Pour tout le reste, la chaîne d’outils Kotlin s’occupe de tout. Pour publier sur Maven Central, vous n’avez pas besoin de déclarer le référentiel manuellement. Il suffit d’ajouter mavenCentral: enabled à votre configuration de publication, puis de configurer tout ce que Maven Central exige. Voici un exemple minimal :
| Code : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 | product: jvm/lib
description: A meaningful description for this specific module
settings:
publishing:
enabled: true
group: com.example # the group has to match your Maven Central namespace
version: 1.0.0
# artifactId is optional, and defaults to your module's name
mavenCentral: enabled
signArtifacts: true # automatically sign your artifacts, no external GPG binary required
publishSources: true
pom:
url: https://example.com
scm: https://github.com/my-org/example.git # the SCM connection and dev connection are automatically derived from this
developers:
- name: John Doe
licenses:
- name: MIT
url: https://opensource.org/license/mit |
Consultez la documentation pour savoir comment fournir les identifiants nécessaires à la signature des artefacts et à leur téléchargement vers le portail Maven Central Publisher. Ensuite, la publication se fait en une seule commande :
| Code : | Sélectionner tout |
kotlin publish mavenCentral
Cette commande compile et signe chaque artefact, les compresse dans un bundle de déploiement Maven Central, télécharge le bundle et attend sa validation. Vous pouvez ensuite vérifier le déploiement et finaliser la publication via l’interface utilisateur du portail Central. Vous pouvez également ignorer la vérification manuelle et automatiser entièrement la publication avec publishingMode: auto si vous faites confiance au pipeline. Consultez la documentation pour en savoir plus sur les modes de publication.
Prise en charge de Cinterop
La chaîne d’outils Kotlin génère désormais des liaisons personnalisées pour les bibliothèques C à partir des fichiers de définition (.def) placés dans le dossier cinterop d’un module.
L’EDI apporte également son aide en générant des liaisons lors du processus de synchronisation du projet.
Améliorations de l’interface utilisateur du terminal
L'équipe de JetBrains a apporté plusieurs améliorations à la sortie de la commande kotlin. Ils ont introduit de meilleurs indicateurs de progression pour les tâches terminées, et la barre de progression principale est intégrée à l’indicateur de progression natif de votre terminal :
Ils ont également amélioré l’affichage des diagnostics signalés par le compilateur JVM Kotlin (nécessite Kotlin 2.4.0 ou une version plus récente) :
Améliorations de l’EDI
Téléchargement des sources des bibliothèques
Les sources des bibliothèques sont désormais téléchargées automatiquement après la synchronisation.
La synchronisation étant terminée en premier, vous pouvez commencer à travailler sur le projet immédiatement tandis que les sources sont téléchargées en arrière-plan.
Résolution des dépendances à l’échelle du module
Auparavant, la résolution des dépendances dans le plugin de l’EDI s’effectuait au niveau du projet, contrairement à la CLI. Cela pouvait entraîner une version de dépendance incorrecte dans un module ou des avertissements erronés dans l’éditeur. Ils ont aligné ce comportement sur celui de la CLI : désormais, chaque module dispose de sa propre portée de résolution, et tous les diagnostics sont identiques.
Améliorations du développement des plugins
De nombreuses nouvelles fonctionnalités sont disponibles pour les auteurs de plugins locaux, notamment les nouvelles déclarations checks et commands, de nouvelles API pour les entrées de tâches et des améliorations au niveau des diagnostics.
Nouvelles références
Lors de la création du fichier plugin.yaml pour configurer les entrées de tâches, quelques références intégrées peuvent être utilisées pour accéder à des informations sur le projet. Ils ont introduit deux nouvelles pour couvrir certains cas courants :
- ${project.rootDir} permet d’accéder au répertoire racine du projet.
- ${module.classes} permet d’accéder au répertoire contenant les fichiers de classes compilés bruts.
Vérifications personnalisées
La nouvelle commande kotlin check est conçue pour s’assurer que le projet passe toutes les vérifications de qualité. Elle exécute par défaut les tests unitaires habituels, et les plugins peuvent enregistrer des vérifications supplémentaires que la commande doit exécuter. Pour introduire une vérification personnalisée dans un plugin, utilisez la liste de niveau supérieur checks :
| Code : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 | # my-lint-plugin/plugin.yaml
tasks:
runLinter:
action: !kotlinJavaLint
sources: ${module.kotlinJavaSources}
checks:
- name: lint
performedBy: runLinter |
Le contrôle lint ci-dessus peut également être exécuté individuellement à l’aide de la commande kotlin check lint. Pour répertorier les contrôles présents dans le projet, utilisez la commande kotlin show checks. Vous trouverez plus d’informations sur les contrôles personnalisés dans la documentation des plugins.
Commandes personnalisées
Il arrive parfois que vous ayez besoin de mettre à disposition un point d’entrée public pour les utilisateurs de votre plugin. Par exemple, vous pourriez vouloir offrir la possibilité de générer un journal des modifications, d’afficher certaines informations à la demande ou de publier un format de distribution personnalisé. Étant donné que les tâches de votre plugin doivent être considérées comme privées par défaut, nous avons introduit un nouveau concept appelé « commandes personnalisées » pour représenter ces points d’entrée publics.
Une commande personnalisée est implémentée à l’aide d’une tâche classique et, à ce titre, elle peut récupérer des données issues de la compilation (telles que des fichiers source, des fichiers JAR compilés ou des informations sur le classpath d’exécution) et dépendre d’autres tâches. Pour enregistrer une commande associée à votre tâche, utilisez la nouvelle section de premier niveau commands dans le fichier plugin.yaml :
| Code : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 10 | # my-lint-plugin/plugin.yaml
tasks:
updateBaseline:
action: !runDetektForBaseline
sources: ${module.kotlinJavaSources}
outputFile: ${module.rootDir}/detekt/baseline.xml
commands:
# shorthand when the name of the command matches that of the task
- updateBaseline |
Vous pouvez ensuite exécuter cette commande personnalisée à l’aide de la nouvelle commande kotlin do command :
| Code : | Sélectionner tout |
kotlin do updateBaseline
Cela exécutera la tâche associée à la commande, ainsi que ses dépendances. Pour lister toutes les commandes personnalisées disponibles dans le projet, utilisez kotlin show commands. Pour en savoir plus sur les commandes personnalisées, consultez la documentation des plugins.
Une nouvelle façon d’enregistrer les fichiers générés
JetBrains a introduit une nouvelle section de niveau supérieur dans plugin.yaml, appelée generated, qui permet d’enregistrer les sources, les ressources et les classes générées. À partir de la version 0.11.0, vous pouvez même enregistrer des définitions `cinterop` lorsque votre tâche provisionne dynamiquement des bibliothèques natives :
| Code : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | tasks:
generateStuff:
action: !myGenerateStuffAction
outputSources: ${taskOutputDir}/src
outputResources: ${taskOutputDir}/res
outputDefFiles: ${taskOutputDir}/cinterop
generated:
sources:
- directory: ${tasks.generateStuff.action.outputSources}
language: kotlin
resources:
- directory: ${tasks.generateStuff.action.outputResources}
cinteropDefinitions:
- directory: ${tasks.generateStuff.action.outputDefFiles} |
Cela remplace la propriété markOutputAs au sein des tâches, qui est obsolète et sera bientôt supprimée. De cette manière, toutes les sorties qui contribuent à la construction sont enregistrées de manière similaire et peuvent être identifiées d’un seul coup d’œil dans leurs sections respectives par des humains, des agents IA et d’autres outils.
Autres améliorations
lib renommé en kmp/lib
Le type de produit lib a été renommé kmp/lib afin de mieux refléter ce qu’il représente suite à l’introduction du type de produit jvm/lib. La valeur lib est obsolète, et JetBrains prévoit de la supprimer dans une prochaine version de la chaîne d’outils Kotlin.
Modèles imbriqués
Les modèles peuvent désormais appliquer d’autres modèles, ce qui vous permet de construire une hiérarchie logique de paramètres. La syntaxe reste la même ; il suffit d’utiliser la section apply dans vos fichiers de modèles :
| Code : | Sélectionner tout |
1 2 3 4 5 6 | # spring.module-template.yaml apply: - ./jvm.module-template.yaml settings: springBoot: enabled |
Prise en charge des classificateurs Maven
Vous pouvez désormais ajouter des classificateurs aux notations de dépendances Maven afin de dépendre d’un artefact spécifique de la bibliothèque, par exemple :
| Code : | Sélectionner tout |
1 2 | dependencies: - io.netty:netty-transport-native-epoll:4.2.13.Final:linux-x86_64 |
Améliorations de la commande run
Ils ont amélioré l’expérience d’utilisation de la commande « run » dans les cas où une seule option est adaptée à l’hôte actuel.
Si le projet comporte plusieurs modules, mais qu’un seul peut s’exécuter sur la machine hôte, il n’est plus nécessaire de spécifier explicitement le module. Par exemple, prenons le projet suivant :
| Code : | Sélectionner tout |
1 2 3 4 5 6 7 8 | . ├── linux-cli/ ├── macos-cli/ ├── windows-cli/ ├── shared/ ├── kotlin ├── kotlin.bat └── project.yaml |
La commande kotlin run lancera le module windows-cli sur une machine Windows. Si le module spécifié comporte plusieurs plateformes cibles et qu’une seule d’entre elles peut être exécutée sur la machine hôte, il n’est plus nécessaire de spécifier explicitement la plateforme. Par exemple, considérons le module suivant :
| Code : | Sélectionner tout |
1 2 3 4 | # linux-app/module.yaml product: linux/app # The platforms linuxArm64 and linuxX64 are both present by default |
La commande kotlin run -m linux-app lancera la version ARM64 de l’application sur une machine ARM et la version x86-64 de l’application sur une machine x86.
Mise à jour des versions par défaut
JetBrains a mis à jour certaines versions par défaut des chaînes d’outils et des frameworks :
- Kotlin 2.3.21
- Compose Hot Reload 1.1.1
- KSP 2.3.7
- Ktor 3.4.3
- SpringBoot 4.0.6
- Lombok 1.18.46
- JUnit Platform 6.0.3
Essayez la chaîne d’outils Kotlin 0.11.0
Pour vous lancer avec la chaîne d’outils Kotlin, consultez le guide de démarrage. Jetez un œil à quelques exemples, suivez un tutoriel ou lisez le guide d’utilisation complet, selon votre style d’apprentissage.
Essayez Kotlin ToolchainSi vous utilisez Amper, vous ne pourrez pas migrer votre installation vers la chaîne d’outils Kotlin via la procédure habituelle de mise à jour automatique. Vous devrez plutôt remplacer les fichiers amper et amper.bat de votre projet par des wrappers Kotlin. Pour ce faire, installez la chaîne d’outils au niveau global, puis utilisez la CLI Kotlin pour générer les nouveaux wrappers Kotlin dans votre projet :
| Code : | Sélectionner tout |
kotlin update --create
Une fois les wrappers remplacés, vous pourrez utiliser la commande kotlin update pour les futures mises à jour.
Partagez vos commentaires
La chaîne d’outils Kotlin est encore en cours de développement. Vous pouvez faire part de vos commentaires sur votre expérience en rejoignant la discussion sur le canal Slack #kotlin-toolchain ou en partageant vos suggestions et idées dans un ticket YouTrack.
Vous avez lu gratuitement 8 658 articles depuis plus d'un an.
Soutenez le club developpez.com en souscrivant un abonnement pour que nous puissions continuer à vous proposer des publications.
Soutenez le club developpez.com en souscrivant un abonnement pour que nous puissions continuer à vous proposer des publications.