Skip to end of metadata
Go to start of metadata





File extension dependent AST transformations








Alex Tkachman



Last modification:


Abstract: What is a file extension dependent AST transformations?

AST transformations is powerful tool for creating DSLs. Two ways to define AST transformations exist today - via annotation and global transformation, which apply to everything. This proposal introduce new type - transformations, which apply only to source files with given extension.

Such approach gives possibility to have better and unified way to organize code base containing groovy based DSLs.

How to implement?

There are two problems to be addressed

  • how to make AST transformation extension aware
  • how to make Groovyc or FileSystemCompiler or even IDE aware about additional (to *.groovy) extensions to be compiled

Interesting that first problem doesn't require any specific handling at all. Global AST transformation can use name of SourceUnit to filter what files to process.

For second problem file META-INF/services/org.codehaus.groovy.transform.ASTTransformation where global AST transformations normally defined can be used. To keep things backward compatible following syntax is suggested


The main benefit of using configuration files are

  • new frameworks using AST based transformations make compiler aware about files to be compiled just by dropping in to classpath
  • it is very easy for any incarnation of compiler (FileSystemCompiler or Groovyc or whatever) to scan classpath and find extensions to be compiled
  • No labels


  1. A minor comment.

    One org.codehaus.groovy.transform.ASTTransformation file can hold multiple global AST transformations. It may be better to specify "#files" at a transformation level. So, if I wanted to some different extensions supported for different global transformations, I can do it like:

    groovy.grape.GrabAnnotationTransformation (#files=groovy)

    org.codehaus.groovy.ast.builder.AstBuilderTransformation (#files=*)

  2. The goal is make this information as easy accessible to groovyc as possible. For example no file parsing should be involved.

    Of course, the file can contain several annotations but usually such file corresponds to one jar/framework, so I do see a problem