Ce projet utilise des bundles binaires sous licence en vertu du contrat d'utilisation de JetBrains (https://www.jetbrains.com/legal/docs/toolbox/user/).
Il s'agit d'une version à accès anticipé de nos plugins Bazel pour IntelliJ, Android Studio et CLion.
Le plugin Bazel est régulièrement téléchargé sur JetBrains Marketplace à partir de l'état de ce référentiel. Voir l'onglet versions pour plus d'informations.
Veuillez consulter notre dernière mise à jour de la communauté pour le plugin Bazel IntelliJ : Annonce de la co-maintenance Bazel et JetBrains du plugin IntelliJ IDEA Bazel.
Le projet Bazel héberge un groupe d'intérêt spécial (SIG) pour le plug-in Bazel IntelliJ IDE. Des détails sur le SIG et comment rejoindre la discussion peuvent être trouvés dans la charte du SIG.
Consultez l'entrée de documentation sur la prise en charge des plugins dans les produits, langages et systèmes d'exploitation JetBrains.
Les plugins Bazel pour IntelliJ et CLion sont construits et publiés à partir de la branche master de ce référentiel. Une équipe externe de responsables résout les problèmes et les demandes d’extraction des plugins IntelliJ et CLion.
Le plugin Bazel pour Android Studio est construit et publié par AOSP. La branche Google est désormais obsolète.
Bien que le code de ce référentiel et celui d'AOSP partagent la même structure et les mêmes composants de base, ils sont différents les uns des autres.
Vous pouvez trouver notre plugin sur JetBrains Marketplace ou directement depuis l'EDI en allant dans Settings -> Plugins -> Marketplace
et en recherchant Bazel
.
Les versions bêta sont généralement téléchargées sur la chaîne bêta 2 semaines avant de devenir des versions complètes. Façons de les installer :
Settings -> Plugins -> Gear Icon -> Manage Plugin repositories
et ajoutez l'une des URL suivantes en fonction de votre produit. Vous pouvez maintenant trouver la dernière version bêta sous Settings -> Plugins -> Marketplace
ou mettre à jour le plugin Bazel vers la version bêta si vous l'avez déjà installé.https://plugins.jetbrains.com/plugins/beta/8609
https://plugins.jetbrains.com/plugins/beta/9554
https://plugins.jetbrains.com/plugins/beta/9185
Nous vous recommandons de regarder cette vidéo pour vous familiariser avec les fonctionnalités du plugin.
Pour importer un projet Bazel existant, choisissez Import Bazel Project
et suivez les instructions de l'assistant d'importation de projet.
Des documents détaillés sont disponibles ici.
Veuillez lire ce commentaire #4745 (commentaire)
Afin d'obtenir une mise en évidence correcte de Python, essayez d'ouvrir la fenêtre "Structure du projet" et d'y définir la "facette Python".
Pour configurer correctement le développement à distance (https://www.jetbrains.com/remote-development/), suivez ces étapes :
Installez Bazel, puis créez la cible *:*_bazel_zip
pour le produit souhaité :
bazel build //ijwb:ijwb_bazel_zip --define=ij_product=intellij-ue-oss-latest-stable
bazel build //clwb:clwb_bazel_zip --define=ij_product=clion-oss-latest-stable
bazel build //aswb:aswb_bazel_zip --define=ij_product=android-studio-oss-latest-stable
à partir de la racine du projet. Cela créera un fichier zip du plugin dans bazel-bin/<PRODUCT>/<PRODUCT>_bazel.zip
, qui peut être installé directement à partir de l'EDI. <PRODUCT>
peut être l'un des ijwb, clwb, aswb
.
Si l'IDE refuse de charger le plugin en raison de problèmes de version, spécifiez le bon ij_product
. Ceux-ci sont sous la forme <IDE>-oss-<VERSION>
avec
<IDE>
étant l'un des intellij-ue, intellij, clion, android-studio
,<VERSION>
étant l'une des oldest-stable, latest-stable, under-dev
. Alternativement, vous pouvez définir ij_product
pour diriger les versions IntelliJ ou CLion, par exemple clion-2023.2
, intellij-2023.2
ou intellij-ue-2023.2
Notez qu'il existe une différence entre intellij
et intellij-ue
. ue
signifie IntelliJ Ultimate Edition et contient des fonctionnalités supplémentaires pour JavaScript ainsi que Go.
<IDE>-oss-oldest-stable
et <IDE>-oss-latest-stable
sont des alias pour les deux versions de l'IDE avec lesquelles le plugin est officiellement compatible à un moment donné. <IDE>-oss-latest-stable
correspond généralement à la dernière version de l'IDE publiée tandis que <IDE>-oss-oldest-stable
correspond à celle juste avant, par exemple <IDE>-oss-oldest-stable=2022.1
et <IDE>-oss-latest-stable=2022.2
. De plus, <IDE>-oss-under-dev
représente la prochaine version de l'IDE que nous travaillons à prendre en charge. Un mappage complet de toutes les versions actuellement définies peut être trouvé dans intellij_platform_sdk/build_defs.bzl
.
Vous pouvez importer le projet dans IntelliJ (avec le plugin Bazel) en important le fichier ijwb/ijwb.bazelproject
.
Vous pouvez créer le plugin pour différentes versions de l'IDE en ajustant l'option ij_product
soit à partir de la ligne de commande, soit en mettant à jour le fichier .bazelproject
pour spécifier la valeur souhaitée pour ij_product
sous build_flags
.
Nous avons trois alias pour les versions du produit ;
oldest-stable
est la version la plus ancienne de l'IDE prise en charge par le plugin Bazel publié sur le canal stable de JetBrains.latest-stable
est la dernière version de l'IDE prise en charge par le plugin Bazel publié sur le canal stable de JetBrains.under-dev
est la version de l'IDE que nous travaillons actuellement à prendre en charge.Les versions IDE correspondantes actuelles de ces alias peuvent être trouvées ici.
Nous apprécions les contributions pour prendre en charge les nouvelles versions de l'IDE. Cependant, pour rendre le processus de révision plus rapide et plus facile, nous recommandons ce qui suit :
Nous ne pouvons accepter que de petites demandes de tirage. Les demandes d'extraction plus petites ont tendance à contenir moins de commentaires d'évaluation et peuvent donc être soumises beaucoup plus rapidement. Ils ont également tendance à moins entrer en conflit avec notre base de code interne, ce qui simplifie l'intégration pour nous. Par exemple, vous devriez avoir des demandes d'extraction distinctes, chacune se concentrant sur un certain changement incompatible plutôt que d'avoir une demande d'extraction volumineuse en corrigeant plusieurs.
Étant donné que nous continuons à prendre en charge un certain nombre de versions de l'IDE tout en travaillant sur une nouvelle, vous devez vous assurer que les modifications proposées ne brisent pas les anciennes versions. Notre pipeline de pré-soumission se chargera de tester vos modifications par rapport à toutes les versions prises en charge et vous permettra de savoir si quelque chose a été cassé.
Pour faciliter la fusion de vos modifications en amont, nous vous recommandons de suivre notre procédure de prise en charge de la rétrocompatibilité du SDK.
Pensez d’abord à ajuster le code du plugin afin qu’il fonctionne directement avec les différentes versions de l’IDE. Des exemples de stratégies pour cela seraient :
Pour les modifications incompatibles non triviales, le code permettant de maintenir la compatibilité du SDK se trouve dans les répertoires sdkcompat et testing/testcompat, où testing/testcompat
contient les modifications de compatibilité du SDK de test uniquement. Chacun des deux répertoires contient un sous-dossier par version de l'IDE prise en charge avec des implémentations spécifiques à la version. L'API externe de toutes les classes doit être la même d'une version à l'autre, seule l'implémentation peut différer. Lorsque vous introduisez un nouveau fichier dans ce répertoire, assurez-vous de le dupliquer de manière appropriée dans toutes les versions.
Nous suivons ces trois techniques pour les changements incompatibles non triviaux.
Compatibilité
Préféré à l’adaptateur et au wrapper le cas échéant. Nous ajoutons une classe util avec uniquement des méthodes statiques et un constructeur privé et encapsulons la méthode modifiée par l'une des méthodes statiques. Si la modification est suffisamment petite, vous n'avez pas besoin de créer une nouvelle classe util et devez plutôt ajouter la modification à la classe BaseSdkCompat. Exemple : pr/2345
Adaptateur
Utilisé lorsque nous étendons une super classe et que son constructeur est mis à jour. Nous créons une nouvelle classe étendant la super classe modifiée, puis étendons cette nouvelle classe à partir du code du plugin. Exemple : pr/2352
Emballage
Créé lorsqu'une nouvelle interface est utilisée dans un constructeur de super classe. Nous créons une classe wrapper qui encapsule et fournit l'ancienne ou la nouvelle interface basée sur la version du SDK et utilisons cette classe wrapper dans le code du plugin. Exemple : pr/2166
Toutes les modifications de compatibilité doivent être commentées avec #api{API_VERSION}
, par exemple #api203
. Cela représente la dernière version de l'API qui nécessite le code, c'est-à-dire celle précédant la version que vous souhaitez prendre en charge. Ceci est nécessaire pour faciliter la recherche et le nettoyage de cette fonctionnalité lors du pavage d'anciennes versions.
Les classes Compat ne doivent jamais importer de code de plugin et nous essayons de garder la logique et le code aussi minimes que possible.
Nous pouvons également être en mesure d'accepter des contributions pour résoudre des problèmes généraux ou ajouter de nouvelles fonctionnalités avec quelques mises en garde :