Spring til indhold
cd /languages
  • Scripting på JVM
  • Programmering
  • AST- og symbolunderstøttelse

Groovy i Maguyva: kodegrafer til Gradle- og Jenkins-kode

Maguyva understøtter Groovy med AST, symboler og graf, så AI-agenter kan følge klasser, closures og kald i Groovy-apps, Gradle-builds og Jenkinsfiles.

Hvor Groovy får overfladiske AI-værktøjer til at snuble

Groovy læses ofte som konfiguration. I et Gradle-build er dependencies { implementation ... } en kæde af metodekald med closures, og det samme gælder en deklarativ Jenkinsfile. Builders gør vilkårlige navne til kald, og GDK tilføjer metoder som each og collect til alle objekter. Et værktøj, der registrerer hvert kald, drukner i den støj.

Maguyva filtrerer DSL- og GDK-laget fra, så dine egne metoder og klasser træder frem.

Hvad Maguyva udtrækker i Groovy

Maguyva dækker .groovy- og .gradle-filer samt Jenkinsfile. Klasser, funktioner og metoder udtrækkes, og imports normaliserer import static- og as-aliaser. Kaldnavne renses for afsluttende closure-blokke og safe-navigation-operatoren ?., så repo?.save(order) { ... } registreres som et kald til save. Et kald uden modtager inde i en klasse slås op til klassens egen metode.

Støj filtreres i lag:

  • Omkring 140 navne fra standardbiblioteket, Gradle og Spock, som dependencies, implementation, task, given, when, then og Mock.
  • Omkring 260 GDK-metoder, som each, collect, inject og eachLine.
  • Builder-DSL-navne, herunder Jenkins-trin som pipeline, stage, steps og sh, når de bruges i builder-stil i stedet for at blive kaldt med parenteser.
  • AST-transformations- og framework-annotationer som @CompileStatic, @Immutable og @Autowired, der aldrig registreres som kald.

Grafen registrerer også nedarvning, instansiering og læsninger og skrivninger.

Eksempler på prompts til agenter

  • “Hvem kalder deployToStaging, og fra hvilke pipelines?” (find_symbol, derefter dependency_search incoming)
  • “Hvilke klasser arver fra BaseIntegrationSpec?” (dependency_search)
  • “Forklar hvordan release-tasken bygger og udgiver artefakter.” (get_task_context)

Kendte begrænsninger

  • Groovy-metoder og frie funktioner deler én syntaksnode, så presettet methods i structural_search vælger intet. Brug i stedet presettet functions eller find_symbol.
  • En egen metode med samme navn som en GDK- eller DSL-metode, som collect eller stage, kan blive filtreret fra sammen med dem. Brug text_pattern_search, når en kalder ser ud til at mangle.

Næste skridt

Tilslut et repository med hurtigstarten, og se derefter understøttelsesmatricen på kompatibilitetssiden. For den JVM-kode, dine builds kompilerer, kan du læse guiden til Java og guiden til Kotlin.

Bedst egnet til

  • > Gradle-builds skrevet i Groovy, hvor delt byggelogik ligger i mange `.gradle`-filer.
  • > Jenkins-pipelines og shared libraries, som agenter skal læse, før CI ændres.
  • > Groovy-applikationer og Spock-testsuiter på JVM.

Agent-arbejdsgange

  • > Finde alle kaldere af et trin i et shared library, før dets argumenter ændres.
  • > Spore hvilke byggescripts der kalder en hjælpefunktion defineret i en fælles `.gradle`-fil.
  • > Kortlægge hvilke klasser der arver fra en basisklasse før en refaktorering.

Motordetaljer

  • > Groovy-understøttelsen dækker `.groovy`, `.gradle` og `Jenkinsfile`. Kaldnavne mister closure-blokke og `?.`-safe-navigation.
  • > Omkring 140 navne fra standardbiblioteket, Gradle og Spock og omkring 260 GDK-metoder filtreres fra relationerne.
  • > Builder-DSL-navne, herunder Jenkins-trin som `stage` og `sh`, filtreres i builder-stil, og annotationer registreres aldrig som kald.

Nyttige MCP-indgange

  • find_symbol

    Brug det til et trin i et shared library, en byggehjælper eller en klasse, når du har brug for definitionen og kalderne.

  • dependency_search

    Brug incoming-traversering på en byggehjælper for at se, hvilke scripts og pipelines der kalder den.

  • text_pattern_search

    Brug det til DSL-kald og GDK-metoder, som filtreres fra grafen.