Skip to content
cd /languages
  • JVM scripting
  • Programming
  • AST and symbol support

Groovy Support in Maguyva: Code Graphs for Gradle and Jenkins Code

Maguyva parses Groovy with AST, symbol, and graph support, so AI agents can follow classes, closures, and calls across Groovy apps, Gradle builds, and Jenkinsfiles.

Where Groovy trips up shallow AI tools

Groovy often reads like configuration. In a Gradle build, dependencies { implementation ... } is a chain of method calls with closures, and a declarative Jenkinsfile is the same. Builders turn arbitrary names into calls, and the GDK adds methods such as each and collect to every object. A tool that records every call drowns in that noise.

Maguyva filters the DSL and GDK layer so your own methods and classes stand out.

What Maguyva extracts in Groovy

Maguyva covers .groovy and .gradle files and Jenkinsfile. Classes, functions, and methods are extracted, and imports normalise import static and as aliases. Call names are cleaned of trailing closure blocks and the ?. safe-navigation operator, so repo?.save(order) { ... } is recorded as a call to save. A bare call inside a class resolves to its own method.

Noise is filtered in layers:

  • About 140 standard-library, Gradle, and Spock names, such as dependencies, implementation, task, given, when, then, and Mock.
  • About 260 GDK methods, such as each, collect, inject, and eachLine.
  • Builder DSL names, including Jenkins steps such as pipeline, stage, steps, and sh, when they are used in builder style rather than called with parentheses.
  • AST-transform and framework annotations such as @CompileStatic, @Immutable, and @Autowired, which are never recorded as calls.

The graph also records inheritance, instantiation, and reads and writes.

Example agent prompts

  • “Who calls deployToStaging, and from which pipelines?” (find_symbol, then dependency_search incoming)
  • “Which classes extend BaseIntegrationSpec?” (dependency_search)
  • “Explain how the release task builds and publishes artifacts.” (get_task_context)

Known limits

  • Groovy methods and free functions share one syntax node, so the methods preset in structural_search selects nothing. Use the functions preset or find_symbol instead.
  • A user method that shares a name with a GDK or DSL method, such as collect or stage, can be filtered with them. Use text_pattern_search when a caller seems missing.

Next steps

Connect a repository with the quickstart, then check the support matrix on the compatibility page. For the JVM code your builds compile, read the Java guide and the Kotlin guide.

Best fit

  • > Gradle builds written in Groovy, where shared build logic lives in many `.gradle` files.
  • > Jenkins pipelines and shared libraries that agents need to read before changing CI.
  • > Groovy applications and Spock test suites on the JVM.

Agent workflows

  • > Find every caller of a shared-library step before changing its arguments.
  • > Trace which build scripts call a helper defined in a common `.gradle` file.
  • > Map which classes extend a base class before a refactor.

Engine details

  • > Groovy support covers `.groovy`, `.gradle`, and `Jenkinsfile`. Call names drop closure blocks and `?.` safe navigation.
  • > About 140 standard-library, Gradle, and Spock names and about 260 GDK methods are filtered from relationships.
  • > Builder DSL names, including Jenkins steps such as `stage` and `sh`, are filtered in builder style, and annotations are never recorded as calls.

Useful MCP entry points

  • find_symbol

    Use it for a shared-library step, build helper, or class when you need the definition and callers.

  • dependency_search

    Use incoming traversal on a build helper to see which scripts and pipelines call it.

  • text_pattern_search

    Use it for DSL calls and GDK methods, which are filtered from the graph.