# Groovy dans Maguyva : des graphes de code pour Gradle et Jenkins Canonical source: https://maguyva.ai/fr/languages/groovy License: text under [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/); code samples under [MIT-0](https://opensource.org/license/mit-0); the Maguyva name, logos, brand assets and other code are not covered. Details: [maguyva.ai/license](https://maguyva.ai/license). Maguyva prend en charge Groovy avec AST, symboles et graphe, pour que les agents IA suivent classes, closures et appels dans les apps Groovy, les builds Gradle et les Jenkinsfiles. ## Aperçu du support - Palier: Prise en charge de l’AST et des symboles - Programmation - Extensions: .gradle, .groovy, .jenkinsfile - Analyse AST réelle pour une recherche consciente de la syntaxe et un contexte structurel. - Les symboles nommés alimentent la recherche sémantique et le référencement croisé. La navigation par graphe est disponible lorsque l’extraction de relations est activée. - Ce langage fournit des symboles et des relations à la recherche tenant compte du graphe ; les types d’arêtes pris en charge varient selon ses constructions natives. - L’analyse AST et l’extraction de symboles sont toutes deux disponibles. ## Idéal pour - Les builds Gradle écrits en Groovy, dont la logique partagée vit dans de nombreux fichiers `.gradle`. - Les pipelines Jenkins et les shared libraries que les agents doivent lire avant de modifier la CI. - Les applications Groovy et les suites de tests Spock sur la JVM. ## Workflows d'agent - Trouver tous les appelants d'une étape de shared library avant de modifier ses arguments. - Retracer quels scripts de build appellent un helper défini dans un fichier `.gradle` commun. - Cartographier les classes qui héritent d'une classe de base avant un refactoring. ## Là où Groovy fait trébucher les outils d'IA superficiels Groovy se lit souvent comme de la configuration. Dans un build Gradle, `dependencies { implementation ... }` est une chaîne d'appels de méthode avec des closures, et un Jenkinsfile déclaratif aussi. Les builders transforment n'importe quel nom en appel, et le GDK ajoute des méthodes comme `each` et `collect` à chaque objet. Un outil qui enregistre chaque appel se noie dans ce bruit. Maguyva filtre la couche DSL et GDK pour que vos propres méthodes et classes ressortent. ## Ce que Maguyva extrait en Groovy Maguyva couvre les fichiers `.groovy` et `.gradle` ainsi que `Jenkinsfile`. Les classes, fonctions et méthodes sont extraites, et les imports normalisent les alias `import static` et `as`. Les noms d'appel sont débarrassés des blocs de closure finaux et de l'opérateur de navigation sûre `?.` : `repo?.save(order) { ... }` est donc enregistré comme un appel à `save`. Un appel sans receveur à l'intérieur d'une classe est résolu vers sa propre méthode. Le bruit est filtré par couches : - Environ 140 noms de la bibliothèque standard, de Gradle et de Spock, comme `dependencies`, `implementation`, `task`, `given`, `when`, `then` et `Mock`. - Environ 260 méthodes du GDK, comme `each`, `collect`, `inject` et `eachLine`. - Les noms de DSL de builder, dont les étapes Jenkins comme `pipeline`, `stage`, `steps` et `sh`, lorsqu'ils sont utilisés en style builder plutôt qu'appelés avec des parenthèses. - Les annotations de transformation d'AST et de framework comme `@CompileStatic`, `@Immutable` et `@Autowired`, qui ne sont jamais enregistrées comme des appels. Le graphe enregistre aussi l'héritage, l'instanciation et les lectures et écritures. ## Exemples de prompts pour agents - « Qui appelle `deployToStaging`, et depuis quels pipelines ? » (`find_symbol`, puis `dependency_search` en incoming) - « Quelles classes héritent de `BaseIntegrationSpec` ? » (`dependency_search`) - « Explique comment la tâche de release construit et publie les artefacts. » (`get_task_context`) ## Limites connues - Les méthodes et les fonctions libres de Groovy partagent un même nœud de syntaxe : le preset `methods` de `structural_search` ne sélectionne donc rien. Utilisez plutôt le preset `functions` ou `find_symbol`. - Une méthode à vous qui porte le nom d'une méthode du GDK ou d'un DSL, comme `collect` ou `stage`, peut être filtrée avec elles. Utilisez `text_pattern_search` quand un appelant semble manquer. ## Étapes suivantes Connectez un dépôt avec le [démarrage rapide](/fr/docs/quickstart), puis consultez la matrice de prise en charge sur la [page de compatibilité](/fr/docs/compatibility). Pour le code JVM que vos builds compilent, lisez le [guide Java](/fr/languages/java) et le [guide Kotlin](/fr/languages/kotlin). ## Détails du moteur - La prise en charge de Groovy couvre `.groovy`, `.gradle` et `Jenkinsfile`. Les noms d'appel perdent les blocs de closure et la navigation sûre `?.`. - Environ 140 noms de la bibliothèque standard, de Gradle et de Spock, et environ 260 méthodes du GDK, sont filtrés des relations. - Les noms de DSL de builder, dont les étapes Jenkins comme `stage` et `sh`, sont filtrés en style builder, et les annotations ne sont jamais enregistrées comme des appels. ## Points d'entrée MCP utiles - `find_symbol`: Utilisez-le pour une étape de shared library, un helper de build ou une classe quand vous avez besoin de la définition et des appelants. - `dependency_search`: Utilisez la traversée incoming sur un helper de build pour voir quels scripts et pipelines l'appellent. - `text_pattern_search`: Utilisez-le pour les appels de DSL et les méthodes du GDK, qui sont filtrés du graphe.