Antlr v4 visitor generation

As I understood it, the intent was to have the Antlr plugin support Antlr 2, 3 and 4 simultaneously. However, unless I am missing something the options exposed by the AntlrTask (there is no AntlrExtension) does not expose any Antlr 3 or 4 settings (no Antlr 4 settings for sure). Is the intention really to have users simply fall back to AntlrTask.arguments for Antlr 4 settings?

As it stands using the Gradle 2.4 version of the Antlr plugin I get listeners generated but no visitors, which happens to be the Antlr 4 tool defaults. However there are no settings for these (nor any of the other Antlr 4 tool options) exposed on AntlrTask…

There’s one here: https://github.com/Abnaxos/gradle-antlr4-plugin

1.0 hasn’t been released yet, so, to use it, you’ll need to add Sonatypes snapshot repository:

buildscript {
    repositories {
        maven {
            url 'https://oss.sonatype.org/content/repositories/snapshots/'
        }
    }
    dependencies {
        classpath group:'ch.raffael.gradlePlugins.antlr4', name:'gradle-antlr4-plugin', version:'1.0-SNAPSHOT'
    }
}

The snapshot already works just fine, it’ll be a matter of a few days until 1.0.

Thanks Raffael. I had been using a “melix” one. Are you familiar enough with that one to compare/contrast yours with it?

I had moved to the Gradle provided one, but clearly it is not up to snuff atm, so I will end up moving to yours or the melix one.

The main problem with melix’ plugin is that it doesn’t respect the package structure. With his plugin, the Java files will be generated straight to the output directory, which e.g. IDEA will mark as an error. My plugin does respect this:

src/main/antlr4/my/dsl/MyDSL.g4$destination/my/dsl/MyDSLParser.java`

It also adds a -package parameter for each file.

The second reason is a future feature: My plugin will start parsing the grammars to determine whether it’s a parser grammar, lexer grammar or combined grammar, and it will first compile lexer grammars. ANTLR needs the Lexer to be compiled before the parser. I’ll implement this before releasing 1.0. This covers the simple use-cases of split grammars. I may also add features to directly support more complex importing of grammars and grammar libraries later.

The third reason is providing an easy way to shadow the antlr4-runtime. The generated code may not be compatible with a different version of the runtime. This is a major source of possibly unresolvable classpath problems: If an external library contains an ANTLR grammar compiled with 4.0 and you’re using ANTLR 4.5 for your own grammar, you will run into a conflict. My plugin provides built-in support for shadowing the runtime with the preshadow plugin (see the example in the README). Every developer using ANTLR should shadow the runtime, so this is actually a must for any ANTLR plugin. I’m even thinking about forcing developers to do it and including this functionality right into the ANTLR plugin.

A small technical reason: My plugin doesn’t spawn a new JVM, it uses the tool directly (including bridging ANTLR error messages to the Gradle log). So, it’s a bit faster.

The melix plugin is basically a shortcut to using javaexec() to invoke the tool, which is fine. But in the end, I always ended up usinga custom task and javaexec() because some of the requirements listed above (which is absolutely an option, BTW, it’s simple to do). It’s fine for most cases (one combined grammar), however, the fact that it doesn’t respect the package for the output files is quite the killer – you can’t just apply the plugin, you’ll have to add it to the buildfile’s classpath and configure the task and sourceSets manually, if you want to avoid IDE-errors about .java files being in the wrong directory.

Cool. I will be watching for a stable release then.

I just released 1.0 (sorry it took so long). It should be available on central and jcenter soon.

Any pointers on where to watch for new releases? Link to your BinTray package?

I’m deploying the plugin to Maven Central through Sonatype OSS, from where it should also be synced to JCenter. I’m currently not using Gradle’s plugin repository (it’s too intrasparent, undocumented and doesn’t support signed artifacts).

buildscript {
  repositories {
    jcenter()
    // and/or mavenCentral() 
  }
  dependencies {
    classpath group:'ch.raffael.gradlePlugins.antlr4', name:'gradle-antlr4-plugin', version:'1.0'
  }
}

apply plugin:'ch.raffael.antlr4'

Examples for direct URLs to the binaries are:

I am asking for places to watch for new releases. None of those offer “watch” capabilities. Your BinTray package (not the JCenter sync) does. If I end up using your plugin in the Hibernate build I’d like to keep up with its development.