Forem: Eric Helgeson

Caching SPA static assets in Grails

Eric Helgeson — Wed, 29 Apr 2020 19:32:23 +0000

If you deploy static assets embedded in your Grails 3 or 4 apps you might notice by default they are not cached - meaning every time a user loads your site - they re-download each asset.

Grails does have a configuration to cache static assets:

application.yml

grails:
    resources:
        cachePeriod: 3600

The problem with this is the entry point index.html is cached as well meaning users won't see updates until after the cache period has elapsed.

The solution is to add a ResourceHandler that matches index.html and sets the cachePeriod to 0

@Component // or add to resources.groovy
class SpaResolverConfig implements WebMvcConfigurer { // WebMvcConfigurerAdapter for Grails 3.x

    // Copied from the GrailsWebMvcConfigurer 
    //  - https://github.com/grails/grails-core/blob/28556c0a1a01d2958d6d3aed251dcacc2a6e38da/grails-plugin-controllers/src/main/groovy/org/grails/plugins/web/controllers/ControllersGrailsPlugin.groovy#L179-L193
    private static final String[] RESOURCE_LOCATIONS = [ "/", "classpath:/META-INF/resources/", "classpath:/resources/", "classpath:/static/", "classpath:/public/" ]

    @Override
    void addResourceHandlers(ResourceHandlerRegistry registry) {
        registry.addResourceHandler('/static/**/index.html') // ant matcher pattern
                .addResourceLocations(RESOURCE_LOCATIONS)
                .setCachePeriod(0) // <-- no-cache
    }
}

Now css/javascript/images from the SPA are cached for 3600 seconds while the index.html file is never cached.

Note: This has no affect on assets using the asset-pipeline plugin - those are cached correctly.

Links:

First saw this issue - https://github.com/grails/grails-core/issues/10410#issuecomment-611572172
Deploying SPA combined with Grails Guide - https://guides.grails.org/grails-vue-combined/guide/index.html

Wiring Micronaut beans in Grails Services

Eric Helgeson — Thu, 02 Apr 2020 15:43:28 +0000

Micronaut beans in Grails 4 are wired by type - not the default Grails users are used to using - wire by name.

For example if we have a micronaut-http-client bean named MyRestClient under src/main/groovy/<package>/MyRestClient.groovy and we want to wire it into the Grails service SomeService we must supply the type:

class SomeService {
    // ❌ wont work, as Grails will look for a bean name that wont exist.
    // def myRestClient

    // ✅ Works!
    MyRestClient myRestClient
}

Tested on Grails 4.0.2.

Deploying Grails 4 to Heroku

Eric Helgeson — Tue, 03 Mar 2020 13:58:50 +0000

Heroku is a PaaS(Platform as a Service) for running web apps that makes it as simple as a git push to deploy. They offer a free tier that is great for demos or quick testing environments and services such as redis, postgres, and many others.

There are a few minor changes from the default heroku gradle build pack to get your Grails 4 app run.

By default heroku will run the task stage to get your app ready. You could add a gradle task named stage or change the default task by running:

$ heroku config:set GRADLE_TASK="assemble"

The Procfile is used to tell heroku how to start your app, in this case, we need to pass the dynamically assigned port to our app, along with heroku's JAVA_OPTS. Lastly, tell it where gradle put our war/jar.

Procfile

web: java -Dserver.port=$PORT $JAVA_OPTS -jar build/libs/*.war

If you'd like to run on OpenJDK 11 - create a system.properties file with the following:

system.properties

java.runtime.version=11

And thats it. Push to Heroku and your app will build and deploy in about a minute.

$ git push heroku master
Enumerating objects: 3, done.
Counting objects: 100% (3/3), done.
Delta compression using up to 8 threads
Compressing objects: 100% (2/2), done.
Writing objects: 100% (2/2), 227 bytes | 227.00 KiB/s, done.
Total 2 (delta 1), reused 0 (delta 0)
remote: Compressing source files... done.
remote: Building source:
remote:
remote: -----> Gradle app detected
remote: -----> Installing JDK 11... done
remote: -----> Building Gradle app...
remote: -----> executing ./gradlew assemble
remote:        > Task :compileJava NO-SOURCE
remote:        > Task :compileGroovy
remote:        > Task :buildProperties
remote:        > Task :processResources
remote:        > Task :classes
remote:        > Task :compileGsonViews
remote:        > Task :findMainClass
remote:        > Task :bootWar
remote:        > Task :war SKIPPED
remote:        > Task :assemble
remote:
remote:        BUILD SUCCESSFUL in 25s
remote:        6 actionable tasks: 6 executed
remote: -----> Discovering process types
remote:        Procfile declares types -> (none)
remote:
remote: -----> Compressing...
remote:        Done: 117.2M
remote: -----> Launching...
remote:        Released v21
remote:        https://my-app.herokuapp.com/ deployed to Heroku
remote:
remote: Verifying deploy... done.
To https://git.heroku.com/my-app.git
   905744b..b239ff4  master -> master

Grails CI with Github Actions

Eric Helgeson — Thu, 14 Nov 2019 00:56:58 +0000

I recently was playing with Github Actions and a Grails 3 app. Was a bit of trial and error though I finally got a working CI workflow.

Github recently added build caching with limitations - this dramatically speeds up your CI builds.

A nice aspect about Actions is you can have actions based on not only pushes/PRs/tags but also things like Github comments. For example /rebase - there's an entire marketplace of actions you can try out.

I've commented the yml file to help you get an understanding of whats going on and how it works.

Full syntax for this yml file can be found here:

https://help.github.com/en/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions

I've also included customized test reporting below - since there is no "results" step to see a junit type report. You can find that below the ream of yml.

.github/workflows/grails.yml

name: Grails CI

# When this workflow will run - here it will run on all pushes but 
# not on branch 'master
on:
  push:
    branches-ignore:
      - 'master'

# A list jobs to run when the condition is met - here we've parallelized
# the build to run test, integrationTest, and assemble.
jobs:
  test:
    runs-on: ubuntu-latest
    # A list of Docker containers you require to run the test
    services:
      postgres:
        image: postgres:latest
        env:
          POSTGRES_USER: postgres
          POSTGRES_PASSWORD: postgres
          POSTGRES_DB: postgres
        ports:
        - 5432:5432

    # Steps in this build 
    steps:
    - uses: actions/checkout@v1
    # We are caching the node_modules, ~/.gradle and app/.gradle   
    # to speed up our build. Caches are automatically stored and restored
    # based on a file hash - in this case yarn.lock and build.gradle
    - name: Cache node modules
      uses: actions/cache@v1
      with:
        path: src/main/vue/node_modules
        key: ${{ runner.os }}-node-${{ hashFiles('**/yarn.lock') }}
        restore-keys: |
          ${{ runner.os }}-node-
    - name: Cache .gradle
      uses: actions/cache@v1
      with:
        path: .gradle
        key: ${{ runner.os }}-dotgradle-${{ hashFiles('**/build.gradle') }}
        restore-keys: |
          ${{ runner.os }}-dotgradle-
    - name: Cache gradle
      uses: actions/cache@v1
      with:
        path: /home/runner/.gradle
        key: ${{ runner.os }}-gradle-${{ hashFiles('**/build.gradle') }}
        restore-keys: |
          ${{ runner.os }}-gradle-
    # Setup JDK 8
    - name: Set up JDK 1.8
      uses: actions/setup-java@v1
      with:
        java-version: 1.8
    # Finally run the test.
    - name: test
      run: ./gradlew test --no-daemon

  # Integration and assemble are much the same
  # though it's yml so not DRY - omitted the copy/paste
  integrationTest:
    steps:
      - name: integrationTest
        run: ./gradlew integrationTest --no-daemon
  assemble:
    steps:
      - name: assemble
        run: ./gradlew assemble --no-daemon

And here is a test formatter that gives you the Spock errors to stdout nicely for debugging as well as a summary:

.gradle/testFormatter.gradle

// From https://stackoverflow.com/a/40656862
import org.gradle.api.tasks.testing.logging.TestExceptionFormat
import org.gradle.api.tasks.testing.logging.TestLogEvent

tasks.withType(Test) {
    testLogging {
        // set options for log level LIFECYCLE
        events TestLogEvent.FAILED,
                TestLogEvent.PASSED,
                TestLogEvent.SKIPPED
        exceptionFormat TestExceptionFormat.SHORT
        showExceptions true
        showCauses true
        showStackTraces true

        // set options for log level DEBUG and INFO
        debug {
            events TestLogEvent.STARTED,
                    TestLogEvent.FAILED,
                    TestLogEvent.PASSED,
                    TestLogEvent.SKIPPED
            exceptionFormat TestExceptionFormat.SHORT
        }
        info.events = debug.events
        info.exceptionFormat = debug.exceptionFormat

        afterSuite { desc, result ->
            if (!desc.parent) { // will match the outermost suite
                def output = "Results: ${result.resultType} (${result.testCount} tests, ${result.successfulTestCount} passed, ${result.failedTestCount} failed, ${result.skippedTestCount} skipped)"
                def startItem = '|  ', endItem = '  |'
                def repeatLength = startItem.length() + output.length() + endItem.length()
                println('\n' + ('-' * repeatLength) + '\n' + startItem + output + endItem + '\n' + ('-' * repeatLength))
            }
        }
    }
}

Removing illegal reflective access warnings in Grails 4

Eric Helgeson — Mon, 15 Jul 2019 14:53:57 +0000

When using JDK11 with Grails 4 you likely have seen these messages:

WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by org.codehaus.groovy.reflection.CachedConstructor$1 (file:/Users/erichelgeson/.gradle/caches/modules-2/files-2.1/org.codehaus.groovy/groovy/2.5.6/6936e700f0fb1b50bac0698ada4347a769d40199/groovy-2.5.6.jar) to constructor com.sun.jmx.mbeanserver.JmxMBeanServer(java.lang.String,javax.management.MBeanServer,javax.management.MBeanServerDelegate)
WARNING: Please consider reporting this to the maintainers of org.codehaus.groovy.reflection.CachedConstructor$1
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release

This is because Groovy 2.5 uses reflection. In Groovy 3 they've already made great strides on this.

For now we can add the correct packages to the --add-opens JVM args to get rid of them.

NOTE: This is the same way Groovy 2.5 removes them when calling groovy with the GROOVY_TURN_OFF_JAVA_WARNINGS environment variable.

In our build.gradle file we can define a list of modules to open:

def jvmOpenModulesArgs = [
        "--add-opens=java.management/com.sun.jmx.mbeanserver=ALL-UNNAMED",
        "--add-opens=java.base/java.io=ALL-UNNAMED",
        "--add-opens=java.base/java.lang=ALL-UNNAMED",
        "--add-opens=java.base/java.lang.annotation=ALL-UNNAMED",
        "--add-opens=java.base/java.lang.invoke=ALL-UNNAMED",
        "--add-opens=java.base/java.lang.module=ALL-UNNAMED",
        "--add-opens=java.base/java.lang.ref=ALL-UNNAMED",
        "--add-opens=java.base/java.lang.reflect=ALL-UNNAMED",
        "--add-opens=java.base/java.math=ALL-UNNAMED",
        "--add-opens=java.base/java.net=ALL-UNNAMED",
        "--add-opens=java.base/java.net.spi=ALL-UNNAMED",
        "--add-opens=java.base/java.nio=ALL-UNNAMED",
        "--add-opens=java.base/java.nio.channels=ALL-UNNAMED",
        "--add-opens=java.base/java.nio.channels.spi=ALL-UNNAMED",
        "--add-opens=java.base/java.nio.charset=ALL-UNNAMED",
        "--add-opens=java.base/java.nio.charset.spi=ALL-UNNAMED",
        "--add-opens=java.base/java.nio.file=ALL-UNNAMED",
        "--add-opens=java.base/java.nio.file.attribute=ALL-UNNAMED",
        "--add-opens=java.base/java.nio.file.spi=ALL-UNNAMED",
        "--add-opens=java.base/java.security=ALL-UNNAMED",
        "--add-opens=java.base/java.security.acl=ALL-UNNAMED",
        "--add-opens=java.base/java.security.cert=ALL-UNNAMED",
        "--add-opens=java.base/java.security.interfaces=ALL-UNNAMED",
        "--add-opens=java.base/java.security.spec=ALL-UNNAMED",
        "--add-opens=java.base/java.text=ALL-UNNAMED",
        "--add-opens=java.base/java.text.spi=ALL-UNNAMED",
        "--add-opens=java.base/java.time=ALL-UNNAMED",
        "--add-opens=java.base/java.time.chrono=ALL-UNNAMED",
        "--add-opens=java.base/java.time.format=ALL-UNNAMED",
        "--add-opens=java.base/java.time.temporal=ALL-UNNAMED",
        "--add-opens=java.base/java.time.zone=ALL-UNNAMED",
        "--add-opens=java.base/java.util=ALL-UNNAMED",
        "--add-opens=java.base/java.util.concurrent=ALL-UNNAMED",
        "--add-opens=java.base/java.util.concurrent.atomic=ALL-UNNAMED",
        "--add-opens=java.base/java.util.concurrent.locks=ALL-UNNAMED",
        "--add-opens=java.base/java.util.function=ALL-UNNAMED",
        "--add-opens=java.base/java.util.jar=ALL-UNNAMED",
        "--add-opens=java.base/java.util.regex=ALL-UNNAMED",
        "--add-opens=java.base/java.util.spi=ALL-UNNAMED",
        "--add-opens=java.base/java.util.stream=ALL-UNNAMED",
        "--add-opens=java.base/java.util.zip=ALL-UNNAMED",
        "--add-opens=java.datatransfer/java.awt.datatransfer=ALL-UNNAMED",
        "--add-opens=java.desktop/java.applet=ALL-UNNAMED",
        "--add-opens=java.desktop/java.awt=ALL-UNNAMED",
        "--add-opens=java.desktop/java.awt.color=ALL-UNNAMED",
        "--add-opens=java.desktop/java.awt.desktop=ALL-UNNAMED",
        "--add-opens=java.desktop/java.awt.dnd=ALL-UNNAMED",
        "--add-opens=java.desktop/java.awt.dnd.peer=ALL-UNNAMED",
        "--add-opens=java.desktop/java.awt.event=ALL-UNNAMED",
        "--add-opens=java.desktop/java.awt.font=ALL-UNNAMED",
        "--add-opens=java.desktop/java.awt.geom=ALL-UNNAMED",
        "--add-opens=java.desktop/java.awt.im=ALL-UNNAMED",
        "--add-opens=java.desktop/java.awt.im.spi=ALL-UNNAMED",
        "--add-opens=java.desktop/java.awt.image=ALL-UNNAMED",
        "--add-opens=java.desktop/java.awt.image.renderable=ALL-UNNAMED",
        "--add-opens=java.desktop/java.awt.peer=ALL-UNNAMED",
        "--add-opens=java.desktop/java.awt.print=ALL-UNNAMED",
        "--add-opens=java.desktop/java.beans=ALL-UNNAMED",
        "--add-opens=java.desktop/java.beans.beancontext=ALL-UNNAMED",
        "--add-opens=java.instrument/java.lang.instrument=ALL-UNNAMED",
        "--add-opens=java.logging/java.util.logging=ALL-UNNAMED",
        "--add-opens=java.management/java.lang.management=ALL-UNNAMED",
        "--add-opens=java.prefs/java.util.prefs=ALL-UNNAMED",
        "--add-opens=java.rmi/java.rmi=ALL-UNNAMED",
        "--add-opens=java.rmi/java.rmi.activation=ALL-UNNAMED",
        "--add-opens=java.rmi/java.rmi.dgc=ALL-UNNAMED",
        "--add-opens=java.rmi/java.rmi.registry=ALL-UNNAMED",
        "--add-opens=java.rmi/java.rmi.server=ALL-UNNAMED",
        "--add-opens=java.sql/java.sql=ALL-UNNAMED"
]

Then add them to our bootRun task:

bootRun {
    jvmArgs('-noverify',
            '-XX:TieredStopAtLevel=1',
            '-Xmx1024m')
    jvmArgs(jvmOpenModulesArgs)
    // ...
}

And any task with GroovyCompile & Test

tasks.withType(GroovyCompile) {
    options.forkOptions.jvmArgs = jvmOpenModulesArgs
}
tasks.withType(Test) {
    jvmArgs = jvmOpenModulesArgs
}

That's it - no more pesky reflective access warnings when the JVM starts up. Thanks to Daniel Sun helping me find the right modules.

Codenarc IntelliJ Plugin Updated

Eric Helgeson — Tue, 21 May 2019 15:52:42 +0000

Codenarc is a static code analysis tool for Groovy. It's been around for quite a while but one feature it lacked was the ability to see the rule violations right inside of IntelliJ.

Luckily one of my co-workers saw that Daniel Demus recently updated the IntelliJ plugin that was originally created by Cédric Champeau.

An example of a rule violation right inside IntelliJ:

You can get the plugin here and check out the code or file a bug on the Github project

One caveat is the plugin currently does not automatically import your codenarc.groovy|xml rule files - you have to enable rules manually in the inspection settings dialog. Though there is a feature request open to do just that.

Grails 3 and Java 11+?

Eric Helgeson — Mon, 20 May 2019 16:41:49 +0000

Sorting out Oracles new JDK release schedule and Grails 3.
Originally posted on https://grails3book.com/

Oracle announced they will be drastically speeding up their JDK releases – one every 6 months with no overlapping public support.

Java 9 was the first in this accelerated release cycle. While these JDK releases come quick, they end just as quickly. As you’re reading this JDK 9 & 10 are already End Of Life(EOL). JDK 11 is the next Long Term Support (LTS) release of the JDK.

With all this news, there has been some confusion about what will support what when and how people should be planning for in regards to Java releases and Grails. I’ll provide a few facts (and a few of my opinions) on what this means to you as a Grails developer.

Let’s start by answering a few concrete questions.

Will Grails 3 build on JDK 9+?

Grails 3.3.x is based on Spring-Boot 1.5. Spring-Boot 1.5 does not and will not support building in JDK 9+.

From Spring-boot's wiki

Spring Boot 2 is the first version to support Java 9 (Java 8 is also supported). If you are using 1.5 and wish to use Java 9 you should upgrade to 2.0 as we have no plans to support Java 9 on Spring Boot 1.5.x.

That’s definitive – you won’t be building Grails 3 apps in anything but JDK7/8 (and that’s ok, keep reading!)

Will Grails 3 run on JDK9+?

This is a much different question -

The answer is yes – Groovy runs (with a few warnings that can be disabled). You will also need to add jaxb explicitly to your CLI or in your dependencies – but it will run. If you use other 3rd party libraries though you will need to validate they will run on JDK9+ as well.

This is great news for user’s environments where you are not able to control your runtime and are forced to run on a newer JDK.

If I’m on JDK8 how long will it be supported?

Oracle has stopped shipping public JDK8 updates as of January 2019. Oracle plans no overlapping publicly supported binaries giving no breathing room for developers.

My recommendation is to switch to one of the many OpenJDK 8 (zulu, amzn, adpt, librca, etc!) distributions which will be supported until at least October 2020+ or pay Oracle for support. If you run on any PaaS such as AWS Elastic Beanstalk you’ve already been running on OpenJDK. sdkman makes it easy to setup OpenJDK on your workstation as well.)

When can I use Java 11 with Grails?

Spring-Boot 2.1 was released (October 30th, 2018.) The Grails team is already working on Grails 4 based on it. Quarter 2 of this year (2019) is the targeted release.

Now for a few of my opinions.

Grails builds on top of many projects such as Spring-Boot, Hibernate, Gradle, etc. All of these projects need to support the latest JDK before Grails can. This IMO is a good thing – it means many compatibility issues and bug fixes can be worked out before I start using it.

What should we do for now?

Spring-Boot 1.5 is maintained until August 1st, 2019 developed and Grails 3 will continue to use it.
Upgrade your apps to Grails 3.3.10 now to make the upgrade path to 4.0.0 simpler. See my Grails 4 Upgrade notes
If you are using Oracles JDK 8 switch to OpenJDK 8 for security updates or pay Oracle for extended support.
Continue to build on JDK 8 and you should be fine running on JDK 11 if you need to.
Stick to LTS JDK releases such as 8 and 11.
Don’t adopt Short Term Support (STS) or end of life JDK’s such as 9/10/13/etc

Conclusion

I use Grails so I don’t have to worry about these compatibility issues – I get a nice package of things that are recent and work together. I’ll be happy to let this JDK madness shake out before I get in the middle of it – I have features to ship to users rather than worry about JDK’s that are only supported for 6 months.

Grails 4 Upgrade Notes

Eric Helgeson — Fri, 17 May 2019 03:17:12 +0000

Grails 4 is the next iteration of the Grails web framework. Grails is a developer friendly framework built on top of Spring-boot, Groovy, and now Micronaut.

Status

Grails 4 is released!

I've ported a non-trivial app from Grails 3.3.9 to 4.0.0 as well as updated to JDK11. The total effort was only a few hours - welcome news to many who are upgrading.

Initial app startup time is about 15 seconds - 2x faster than the same app in Grails 3.3.9.

Reloading has changed and there are a few options. The default option is from spring-dev-tools - fast restart. This restarts your app faster then a normal restart, but still can be extremely slow for large projects.

Hot reloading options are JRebel - a paid option that works for JDK8/11 - or spring-loaded though it only supports JDK8 and is no longer maintained. Instructions for spring-loaded

IDE Support all works in Grails 4 (same as 3.3.9) - IntelliJ is still my recommended IDE for any Grails, Groovy, or Java developer.

Updates

There are tons of updates to Grails 4 and the frameworks it builds upon. Here's a list of updates and release notes you should review if you're updating your apps.

Grails 4
- Upgrade notes
- New app diff from 3.3.10 -> 4.0.0
Micronaut 1.1
Spring Boot 2.1
Spring 5.1
Groovy 2.5
Hibernate 5.3/5.4 support
Java 11

Install

SDKMan makes installing and managing a JVM and many frameworks a snap:

sdk install java 11.0.2-open
sdk install grails 4.0.3

Plugins

Plugins are an essential part of the Grails developer experience. Luckily many plugins that worked in Grails 3 work out of the box in Grails 4 - or with only slight modifications due.

Working Plugins

Spring-Security-Core 4.0.0
- New delegation password strategy:
- https://www.baeldung.com/spring-security-5-password-storage
- If you already used bcrypt can do it all at once too:
- UPDATE my_users SET password = CONCAT('{bcrypt}', password);
Spring-session-redis (boot starter)
- Updated dependencies

compile "org.springframework.boot:spring-boot-starter-data-redis"
compile "org.springframework.session:spring-session-data-redis"

Spring-Websocket

compile "org.grails.plugins:grails-spring-websocket:2.5.0.RC1"

Grails-Quartz

buildscript {
    dependencies {
        classpath 'org.grails.plugins:quartz:2.0.13' // Needed to compile *Job classes
    }
}

dependencies {
    compile 'org.grails.plugins:quartz:2.0.13'
    compile 'org.quartz-scheduler:quartz:2.2.1' // Is not pulled in by default
}

Database Migration Plugin 3.1.0.RC1
Asset-Pipeline 3.1.0
External Config
- Works - use RC1+

    compile 'org.grails.plugins:external-config:2.0.0'

Spring Security UI
- https://github.com/grails-plugins/grails-spring-security-ui/issues/111
Schwartz Plugin
- 2.0.0.RC1
Grails Cache Plugin
- 5.0.0.RC1
Spring Security OAuth2 Provider
- 4.0.0-RC1
Sentry
Grails Mail
- 3.0.0

Not working

Audit-Logging Plugin
- WIP @ https://github.com/robertoschwald/grails-audit-logging-plugin/pull/183

Resolved

~~Asset Pipeline Handlebars issue:~~
- Needed to update to change //= require handlebars/handlebars.js to //= require handlebars-runtime

2019-01-13 16:59:42.280  WARN --- [nio-8080-exec-1] asset.pipeline.DirectiveProcessor        : Unable to Locate Asset: /handlebars/handlebars.js
Warning: Nashorn engine is planned to be removed from a future JDK release

~~Gson Views~~
- Resolved.
- Unable to render json with simple objects (just get null response)
- Domain classes dont render:

  Model variable [someDomain] of with value [Description] type [com.x.SomeDomain] is not of the correct type [com.x.SomeDomain]. Stacktrace follows:

Opened Issue https://github.com/grails/grails-views/issues/202

Other notes Notes

Hot reload for JDK8 only
- spring-loaded supports only up to JDK8.
- Fast reload takes about 5-6 seconds (hopefully can improve)
org.grails:grails-datastore-rest-client no longer maintained
- Use a different http client such as
  - micronaut-http-client, http-builder-ng, feign, okhttp, etc
- Or use the old unmaintained GORM 6 version:

compile('org.grails:grails-datastore-rest-client:6.1.9.RELEASE'){
    exclude group:'org.grails', module:'grails-plugin-converters'
}

Groovy 2.5.x
- Doesn't include the Date Utils helpers by default - need to add them in.
- compile 'org.codehaus.groovy:groovy-dateutil'
- (Should just update to java.time.*)
- JDK 11 Warnings (expected)
- https://dev.to/erichelgeson/removing-illegal-reflective-access-warnings-in-grails-4-393o
- .pop() & collections behavior changed to align with Java - https://issues.apache.org/jira/browse/GROOVY-9388
Dependencies changes (Gradle 5.1)
- An issue where dependencies like com.jameskleeh:excel-builder - don't pull in their dependencies (eg: Apache POI)
Hibernate Deprecated warnings (expected)

Hibernate's legacy org.hibernate.Criteria API is deprecated; use the JPA javax.persistence.criteria.CriteriaQuery instead
// and
HHH020100: The Ehcache second-level cache provider for Hibernate is deprecated.  See https://hibernate.atlassian.net/browse/HHH-12441 for details.

Hide them in logback.groovy
- logger('org.hibernate.orm.deprecation', ERROR, ['STDOUT'], false)

Notes or tips of your own?

Join us over on the grails-community slack channel or comment below!