Прощай, Grails. Привет, Micronaut / Habr

Всего в цикле публикаций о миграции из Grails в Micronaut будет 10 частей:

Многомодульный проект
Конфигурация
Статическая компиляция
Датасеты
Маршалинг
Классы предметной области
Сервисы
Контроллеры
Приложение Micronaut
Micronaut Data

Обратите внимание: ваше приложение должно быть создано в Grails 4.x или более поздней версии.

Часть 1. Многомодульный проект

Мы начинаем цикл статей с инструкциями, которые помогут вам шаг за шагом мигрировать из Grails. Итак, для начала нужно извлечь компоненты вашего приложения в отдельные библиотеки. Это лучше всего сделать путем создания многомодульного проекта (в документации Gradle — multi-project). Чтобы создать структуру, которую будет легко масштабировать, мы воспользуемся набором плагинов Kordamp Gradle.

Сперва перенесем все, что имеет отношение к вашему приложению, в отдельную папку apps/<имя-вашего-приложения>. Далее во всех инструкциях этого цикла мы будем писать hello там, где должно быть имя вашего приложения. Таким образом, у нас получится новый путь apps/hello. Файлы Gradle перемещать не нужно, за исключением файла build.gradle (ему следует присвоить имя, совпадающее с именем папки, в которую он перемещен; в нашем примере — hello.gradle). Файлы Grails Wrapper можно удалить.

├── .gitignore
├── build.gradle
├── gradle
│   └── wrapper
│       ├── gradle-wrapper.jar
│       └── gradle-wrapper.properties
├── gradle.properties
├── gradlew
├── gradlew.bat
├── grails-app
├── grails-wrapper.jar
├── grailsw
├── grailsw.bat
└── src

Вот так будет выглядеть структура папок в проекте после перемещения всех файлов:

├── .gitignore
├── apps
│   └── hello
│       ├── grails-app
│       ├── hello.gradle
│       └── src
├── gradle
│   └── wrapper
│       ├── gradle-wrapper.jar
│       └── gradle-wrapper.properties
├── gradle.properties
├── gradlew
└── gradlew.bat

Далее создаем файл setting.gradle, с помощью которого будут установлены плагины Kordamp Gradle:

buildscript {
    repositories {
        gradlePluginPortal()
    }
    dependencies {
        classpath 'org.kordamp.gradle:settings-gradle-plugin:0.46.0'
    }
}
apply plugin: 'org.kordamp.gradle.settings'

rootProject.name = 'hello-root'

projects {
    directories = ['apps', 'libs']
}

В переменной rootProject.name следует объявить название проекта, добавив -root, чтобы избежать конфликта имен. Благодаря плагинам Kordamp Gradle все подпапки внутри папок app и libs автоматически определятся как подпроекты.

Теперь создаем новый файл build.gradle в корневой папке. Меняем значения на свои:

plugins {
    id 'org.kordamp.gradle.groovy-project' version '0.46.0'
}

config {
    release = (rootProject.findProperty('release') ?: false).toBoolean()

    info {
        name        = 'Sample'
        vendor      = 'Acme'
        description = 'Sample project'

        links {
            website      = 'https://github.com/me/repo'
            issueTracker = 'https://github.com/me/repo/issues'
            scm          = 'https://github.com/me/repo.git'
        }

        people {
            person {
                id    = 'joecool'
                name  = 'Joe Cool'
                roles = ['developer']
            }
        }
    }

    licensing {
        enabled = false
    }
}

allprojects {
    repositories {
        mavenCentral()
    }
}

Наконец необходимо явно объявить класс приложения (в нашем примере — hello.Application) в подпроекте apps/hello/hello.gradle, иначе произойдет конфликт конфигурации плагинов Gradle и приложение не запустится:

springBoot {
    mainClassName = 'hello.Application'
}

Теперь пробуем запустить приложение с помощью команды ниже, чтобы проверить, все ли в порядке:

./gradlew bootRun

Следующий шаг — перенос конфигурации из Grails в объекты конфигурации Micronaut.

Часть 2. Конфигурация

Продолжаем плавно мигрировать из Grails: теперь разберемся с доступом к конфигурации.

В Grails можно получить доступ к файлам конфигурации из объекта GrailsApplication или с помощью статических методов класса Holders.

@CompileDynamic 
class MyService {

    GrailsApplication grailsApplication
    
    String returnFoo() {
        // normal access
        return grailsApplication.config.agorapulse.foo
    }
    
    String returnBar() {
        // static access
        return Holders.config.agorapulse.bar
    }

}

Grails 4.x и старше уже поддерживает Micronaut, так что можно пользоваться возможностями последнего, в том числе взаимодействовать с объектами свойств конфигурации. Можно, например, создать простой объект для привязки значений конфигурации:

@CompileStatic 
@ConfigurationProperties('agorapulse')
class AgorapulseConfiguration {
    
    String foo
    String bar

}

Этот объект можно интегрировать в любой сервис Grail. К полю нужно добавить аннотацию @Inject, так как автоматическая привязка для бинов Micronaut уже не работает.

@CompileStatic
class MyService {

    @Inject AgorapulseConfiguration configuration

    String returnFoo() {
        return configuration.foo
    }

    String returnBar() {
        return configuration.bar
    }

}

Не лишним также будет добавить дополнительную проверку класса конфигурации. Теперь ваш сервис полностью готов к внедрению статической компиляции.

В следующей части мы расскажем, как реализовать статическую компиляцию для всего проекта Grails.

Часть 3. Статическая компиляция

Переход в другую экосистему — всегда непростая задача, даже если это родственный фреймворк. Чтобы миграция прошла успешно, стоит внедрить статическую компиляцию в качестве дополнительного уровня безопасности в масштабе приложения. Это также поможет на следующих этапах миграции при рефакторинге моделей предметной области. Процедура внедрения статической компиляции подробно описана в статье по ссылке ниже: рекомендуем сначала прочитать ее.

Мы хотим внедрить статическую компиляцию во все приложения и библиотеки проекта, поэтому обновляем файл settings.gradle следующим образом:

projects {
    directories = ['apps', 'libs']

    plugins {
        dirs(['apps',  'libs']) {
            id 'groovy'
            id 'java-library'
        }
    }
}

Эти строки гарантируют, что во всех подпроектах apps и libs будут работать плагины groovy и java-library.

Теперь для внедрения статической компиляции в масштабе приложения нужно настроить зависимость Enterprise Groovy. Дописываем этот код в файл build.gradle:

projects {
    subprojects {
        dirs(['apps', 'libs']) {
            // add Enterprise Groovy library
            dependencies {
                compileOnly 'com.virtualdogbert:enterprise-groovy:1.0.3'
            }
            
            // configure Enterprise Groovy library
            compileGroovy.groovyOptions.configurationScript = 
                rootProject.file('config/groovy/conventions.groovy')
        }  
    }
}

Создаем файл конфигурации, упомянутый выше, в папке config/groovy/conventions.groovy:

Map conventions = [
    disable                     : false,
    whiteListScripts            : true,
    disableDynamicCompile       : false,  
    dynamicCompileWhiteList     : [
                'UrlMappings',
                'Application',
                'BootStrap',
                'resources', 
                'org.grails.cli'
    ],
    limitCompileStaticExtensions: false,
    defAllowed                  : false,    // For controllers you can use Object in place of def, and in Domains add Closure to constraints/mappings closure fields.
    skipDefaultPackage          : true,     // For GSP files
    compileStaticExtensions     : [
      'org.grails.compiler.ValidateableTypeCheckingExtension',
      'org.grails.compiler.NamedQueryTypeCheckingExtension',
      'org.grails.compiler.HttpServletRequestTypeCheckingExtension',
      'org.grails.compiler.WhereQueryTypeCheckingExtension',
      'org.grails.compiler.DynamicFinderTypeCheckingExtension',
      'org.grails.compiler.DomainMappingTypeCheckingExtension',
      'org.grails.compiler.RelationshipManagementMethodTypeCheckingExtension'
    ],
]
System.setProperty(
    'enterprise.groovy.conventions', 
    "conventions=${conventions.inspect()}"
)

Простые действия закончились, переходим к более сложным манипуляциям.

Даже если вы все делали верно на предыдущих шагах, вы можете столкнуться с ошибками компиляции при запуске команды ./gradlew classes в терминале. У Enterprise Groovy есть один недостаток: результаты статической компиляции не отображаются в явном виде в IDE. Поэтому рекомендуем добавлять аннотации @CompileStatic или @GrailsCompileStatic к классам, которые не прошли компиляцию: так вы увидите все ошибки прямо в вашей среде разработки. Если какие-либо части кода не компилируются, добавьте к ним аннотацию @CompileDynamic. Учтите, что динамическую компиляцию следует использовать в минимальном масштабе. Бонус: в результате код вашего приложения будет более устойчивым к ошибкам и будет меньше риска при его рефакторинге.

В следующей части мы будем готовить датасеты для классов предметной области. Они послужат основой для тестирования, которое мы будем проводить далее, чтобы гарантировать успешную миграцию.

Источники и обсуждение:

GitHub - agorapulse/goodbye-grails-hello-micronaut: Goodbye Grails, Hello Micronaut

github.com

Оригинальные публикации: часть 1, часть 2, часть 3.

Материал подготовлен в рамках курса «Groovy Developer».
Всех желающих приглашаем на бесплатное demo-занятие «Знакомство с Micronaut». Micronaut представляет собой легковесный фреймворк на основе JVM для создания приложений на основе микросервисов. На занятии мы рассмотрим возможности фреймворка, такие как compile time DI, создание native image, serverless функции, и другие.
>> РЕГИСТРАЦИЯ