Объединение Gradle с Antlr3

Я прошел относительно безболезненный процесс преобразования Гобелена из Maven в Gradle , и я в восторге от результатов. До сих пор моим самым большим камнем преткновения было использование Antlr3 компанией Tapestry для языка выражения свойств .

Встроенная поддержка Antlr дошла только до Antlr2. Плагин Maven, который я использовал, понял Antlr3. После небольшого исследования и взлома, это то, что я придумал как решение для Гобелена:

description="Central module for Tapestry, containing all core services and components"

antlrSource = "src/main/antlr"
antlrOutput = "$buildDir/generated-sources/antlr"

configurations {
  antlr3
} 

sourceSets.main.java.srcDir antlrOutput

dependencies {
  compile project(':tapestry-ioc')
  compile project(':tapestry-json')
  
  provided project(":tapestry-test")
  provided "javax.servlet:servlet-api:$servletAPIVersion"

  compile "commons-codec:commons-codec:1.3"

  // Transitive will bring in the unwanted string template library as well
  compile "org.antlr:antlr-runtime:3.3", { transitive = false }

  // Antlr3 tool path used with the antlr3 task
  antlr3 "org.antlr:antlr:3.3"
}

// This may spin out as a plugin once we've got the details down pat

task generateGrammarSource {
  description = "Generates Java sources from Antlr3 grammars."
  inputs.dir file(antlrSource)
  outputs.dir file(antlrOutput)
} << {
  mkdir(antlrOutput)
  
  // Might have a problem here if the current directory has a space in its name
  
  def grammars = fileTree(antlrSource).include("**/*.g")
    
  ant.java(classname: 'org.antlr.Tool', fork: true, classpath: "${configurations.antlr3.asPath}") {
     arg(line: "-o ${antlrOutput}/org/apache/tapestry5/internal/antlr")
     arg(line: grammars.files.join(" "))
  }
}

compileJava.dependsOn generateGrammarSource

Суть здесь в том, чтобы создать конфигурацию (своего рода путь к классу) только для запуска класса Antlr Tool. Новая задача находит файлы грамматики и передает их в инструмент. Мы также направляем вывод инструмента в качестве пути поиска для основной задачи компиляции Java. Наконец, мы определяем входы и выходы для задачи, чтобы Gradle мог решить, нужно ли вообще запускать задачу.

Часть удовольствия от Gradle заключается в том, что он все еще является скриптом Groovy, поэтому есть привычный и унифицированный синтаксис для определения переменных и выполнения других не декларативных вещей, таких как создание списка файлов грамматики для Инструмента.

Как можно догадаться из некоторых комментариев, это что-то вроде первого прохода; плагин Maven был немного лучше в сборке списка имен входных файлов таким образом, что класс Antlr3 Tool знал, где правильно написать выходные исходные файлы Java; если бы Гобелен использовал несколько грамматик в нескольких разных местах, решение, приведенное выше, было бы недостаточно. Также кажется обходным использование Ant для запуска Java-приложения … Я не нашел более простого способа (хотя я не сомневаюсь, что он спрятан в документации Gradle).

Мой опыт получения этой работы был в основном положительным; Помогло очень большое количество документации для Gradle, хотя это может быть немного утомительно, так как необходимая информация часто разбросана по сочетанию ссылок Gradle DSL , Руководства пользователя , Javadoc и GroovyDoc . Слишком часто кажется, что решение становится понятным только после его завершения, работая в обратном направлении от некоторых внутренних деталей Gradle (например, какие именно классы он выбирает для создания экземпляров в данной ситуации) обратно через различные интерфейсы, классы Java и расширения Groovy MetaObject. к этим классам.

Фактически, ключевые части того, что я в конечном счете достиг, были обнаружены с помощью веб-поиска, а не в документации. Но это также означает, что система работает.

Конечно, это горшок, называющий чайник чёрным … можно перефразировать одну критику Гобелена, поскольку мы можем настроить его на что угодно, всего лишь за несколько строк кода, но может потребоваться три дня, чтобы выяснить, где эти строки кода идут .

В конце дня я намного счастливее с Gradle; процесс сборки быстрее, скрипты сборки крошечные и намного проще в обслуживании, а отзывы от инструмента превосходные. Есть еще много вопросов для решения … в основном с точки зрения инфраструктуры Apache и Maven:

• Обеспечение правильного создания артефактов Maven с правильными зависимостями в сгенерированном pom.xml
• Генерация архетипа Maven с использованием Gradle
• Создание документации по компонентам JavaDoc и Tapestry с помощью Gradle, а также минимальное количество страниц для их связывания (сродни плагину для сайта Maven)
• Генерация исходного и бинарного артефактов и правильная загрузка всего на Apache Nexus