grails create-app my-app
3 Upgrading from the previous versions
Version: 6.2.1
Table of Contents
3 Upgrading from the previous versions
3.1 Upgrading from Grails 5 to Grails 6
Upgrade Instructions for Grails and Related Dependencies
To ensure compatibility with Grails 6, you must update the following versions in your project:
1. Java 11 as Baseline:
Starting from Grails 6, Java 11 serves as the baseline requirement for the framework. When upgrading to Grails 6, ensure that your project is configured to use Java 11. This compatibility with Java 11 allows you to take advantage of the latest features, security enhancements, and performance improvements provided by Java 11.
Please make sure to update your project’s Java version to 11 before proceeding with the Grails 6 upgrade. Doing so will ensure a seamless transition to the latest version of Grails and enable you to enjoy all the benefits that Java 11 has to offer.
2. The New Grails CLI:
Grails 6 comes with a completely revamped and highly efficient Command Line Interface (CLI) that enables you to generate applications and plugins at a remarkable speed. For instance, you can now use the new CLI to create a new Grails 6 application with the following command:
The new CLI also allows you to generate plugins easily. For example, to create a new plugin named "my-plugin," you can use the following command:
grails create-plugin my-plugin
One notable improvement in Grails 6 is that it no longer supports certain commands that performed redundant tasks, such as the outdated grails run-app
command. Instead, it recommends using the Gradle bootRun
task for running your application, which offers better performance and functionality.
For example, to run your Grails 6 application, you can use the following command:
./gradlew bootRun
As a result of these improvements, the new CLI provides a more streamlined and efficient way to work with Grails applications and plugins.
Overall, Grails 6 offers a significantly improved development experience with its new CLI, optimized commands, and advanced features for generating applications and plugins.
3. Setting Grails Version and Grails Gradle Plugin:
To upgrade to Grails 6, it’s important to configure the appropriate versions in the gradle.properties
file as shown below:
grailsVersion=6.0.0
grailsGradlePluginVersion=6.0.0
By specifying the above versions, you’ll gain access to the latest features, improvements, and bug fixes introduced in Grails 6. Upgrading to this version empowers your application with enhanced performance and improved security. Additionally, it allows you to leverage the latest advancements in the Grails framework for a more efficient and secure development experience.
4. GORM Version:
If your project utilizes GORM, ensure to update the version in the gradle.properties
file as demonstrated below:
gormVersion=8.0.0
By upgrading to GORM 8.0.0, you will benefit from essential updates and optimizations. This upgrade guarantees seamless interactions with your database and enhances your data management experience. Staying current with GORM allows you to take advantage of the latest database features and improvements, thereby optimizing the performance and functionality of your application.
5. Gradle Version:
Grails 6 uses Gradle 7.6.2 which offers performance improvements, bug fixes, and new features over previous versions. Upgrading to the latest Gradle version helps accelerate your build processes and ensures compatibility with other dependencies.
5.1. Upgrade to Gradle 7.6.2
Run the following command to update the Gradle wrapper to the desired version (e.g., Gradle 7.6.2):
./gradlew wrapper --gradle-version 7.6.2
This command will download the specified Gradle version and update the Gradle wrapper settings in your project.
5.2. Check Gradle Version:
After the command finishes, you can verify that the Gradle version has been updated by checking the gradle-wrapper.properties
file located in the gradle/wrapper
directory. The distributionUrl
in the file should now point to the Gradle 7.6.2 distribution:
distributionUrl=https\://services.gradle.org/distributions/gradle-7.6.2-bin.zip
5.3. Build the Project:
After updating the Gradle wrapper, you can now build your Grails project using the updated Gradle version:
./gradlew build
This will initiate the build process with the new Gradle version.
6. Embracing Modern Plugin Management with Grails 6
In Gradle, there are two main ways to add plugins to your project: the plugins
block and the apply plugin
statement.
Grails 6 introduces a significant change in how plugins are managed by adopting the Gradle plugins
block instead of the traditional apply plugin
statements. This shift streamlines the project’s build configuration and brings it more in line with modern Gradle conventions. New Grails projects will now utilize the plugins
block to manage plugin dependencies and configurations.
Using the plugins
Block in Grails 6:
With the new approach, adding plugins to a Grails 6 project is more explicit and organized. In your build.gradle
file, you can declare plugins within the plugins
block, specifying the plugin’s ID and version.
Here’s an example of adding the views-json
plugin using the plugins
block:
plugins {
id 'org.grails.plugins.views-json' version '3.0.0'
}
Managing Multiple Plugins:
The plugins
block allows you to add multiple plugins, each on its own line. This enhances clarity and makes it easier to manage plugin dependencies.
plugins {
id 'org.grails.plugins.views-json' version '3.0.0'
// Add other plugins as needed
}
Moving Older Applications to the New Approach:
If you are migrating an older Grails application to Grails 6, you can update the plugin declarations from apply plugin
to the plugins
block. For example, if your previous application used the views-json
plugin, you can modify the build.gradle as follows:
Before (Using apply plugin
):
apply plugin: 'org.grails.plugins.views-json'
After (Using plugins
Block in Grails 6):
plugins {
id 'org.grails.plugins.views-json' version '3.0.0'
}
By migrating to the plugins
block, your Grails 6 project will adhere to modern Gradle conventions, making it easier to manage plugin dependencies and configurations. This new approach maintains consistency and enhances the overall structure of the project, ensuring a smoother and more efficient development process.
6.2. Use the pluginManagement Block
Moving from apply plugin
in the build.gradle
file to the pluginManagement
block in the settings.gradle
file is a significant change introduced in Grails 6. This change is part of Grails' effort to adopt the Gradle pluginManagement
approach for better plugin version control and consistency across projects.
In the previous versions of Grails (before Grails 6), developers used to apply plugins directly in the build.gradle
file using the apply plugin
syntax. For example:
buildscript {
repositories {
maven { url "https://plugins.gradle.org/m2/" }
maven { url "https://repo.grails.org/grails/core" }
}
dependencies {
classpath "org.grails:grails-gradle-plugin:$grailsGradlePluginVersion"
classpath "org.grails.plugins:hibernate5:7.3.0"
classpath "org.grails.plugins:views-gradle:2.3.2"
}
}
version "0.1"
group "hellorestapi"
apply plugin:"eclipse"
apply plugin:"idea"
apply plugin:"war"
apply plugin:"org.grails.grails-web"
apply plugin:"org.grails.plugins.views-json"
However, with Grails 6, the recommended practice is to move plugin declarations to the pluginManagement
block in the settings.gradle
file. The pluginManagement
block acts as a central place to manage plugin versions for all projects within a multi-project build.
Configuring Plugins in the pluginManagement Block:
Here’s how you can declare the views-json
plugin in the pluginManagement
block:
-
Open the
settings.gradle
file in your Grails 6 project. -
Add the
pluginManagement
block with theviews-json
plugin declaration:
pluginManagement {
repositories {
// Add the Grails plugin repository to resolve the views-json plugin
maven { url "https://repo.grails.org/grails/core" }
// Other repositories can be added here if needed
}
// Declare the views-json plugin and its version
plugins {
id 'org.grails.plugins.views-json' version '3.0.0'
// Other plugins can be declared here
}
}
By including the views-json
plugin in the pluginManagement
block, Grails 6 will ensure that all projects within the multi-project build use the specified version of the views-json
plugin. This promotes consistency in JSON rendering across different projects and simplifies maintenance and version control.
Moving Older Applications to the New Approach:
If you are migrating an older Grails application to Grails 6, you can update the plugin declarations from apply plugin
to the plugins
block in the build.gradle
file, as shown in the previous section.
By adopting the pluginManagement
block and declaring the views-json
plugin in the settings.gradle
file, you ensure consistent usage of the plugin across all projects in the Grails 6 ecosystem. This approach simplifies plugin version control and improves the overall development experience when working with JSON responses in your Grails applications.
6.3 Grails Adoption of "buildSrc" Folder for Buildscript Dependencies
In previous versions of Grails (before Grails 6), managing buildscript dependencies, such as the views-gradle
plugin, was typically done directly in the main build.gradle
file. This enables Gradle compilation of JSON views for production environment. Developers would define the repositories and dependencies needed for the buildscript within the buildscript
block:
buildscript {
repositories {
mavenCentral()
}
dependencies {
// Example: views-gradle plugin
classpath "org.grails.plugins:views-gradle:3.0.0"
}
}
// Apply the views-json plugin
apply plugin: 'views-json'
// Other configurations and dependencies
This approach meant that the buildscript dependencies were mixed with the rest of the project’s configurations, making the build.gradle
file longer and potentially harder to maintain. As a result, the buildscript section might become cluttered with various plugin dependencies and other build logic.
With the introduction of Grails 6, there is a significant improvement in managing buildscript dependencies through the use of the buildSrc
folder. This dedicated folder provides a more organized approach to handle buildscript dependencies, custom Gradle plugins, and extensions specific to the project.
Benefits of Grails 6 Adoption of "buildSrc" Folder
-
Modular Build Configuration: The
buildSrc
folder acts as a separate mini-project within your Grails application, allowing you to encapsulate build logic, plugins, and dependencies. This separation of concerns improves the organization and modularity of the build configuration. -
Streamlined Buildscript Management: By moving buildscript dependencies to
buildSrc
, you can keep the mainbuild.gradle
file clean and focused on the application’s specific requirements. This reduces clutter and promotes a more concise and clear build script. -
Better Collaboration: The
buildSrc
approach simplifies collaboration within development teams. Build logic can be centralized and shared across projects, enabling a consistent and efficient development workflow.
Update from Grails 5
The new Grails 6 application uses buildSrc/build.gradle
. The buildSrc directory can host a build script if additional configuration is needed (e.g. to apply plugins or to declare dependencies). The buildSrc
folder in a Grails project follows a specific tree layout, which includes the build.gradle
file. Here’s how the tree layout looks like:
buildSrc/
├── build.gradle
└── src/
└── main/
└── groovy/
Let’s walk through how to manage the views-gradle
plugin using the buildSrc
folder in Grails 6:
Step 1: Create buildSrc Folder:
In the root directory of your Grails 6 project, create a new folder named buildSrc
.
Step 2: Add buildSrc Script:
Inside the buildSrc
folder, create a build.gradle file and specify the views-gradle
plugin dependency:
repositories {
mavenCentral()
}
dependencies {
implementation "org.grails.plugins:views-gradle:3.0.0"
}
Step 3: Remove apply plugin Statement:
In the main build.gradle
file, remove the buildscript
block and the apply plugin
statement related to views-gradle
, as it is now managed in the buildSrc
folder:
buildscript {
repositories {
mavenCentral()
}
dependencies {
classpath "org.grails.plugins:views-gradle:3.0.0"
}
}
// No need to apply views-json plugin here
// Remove the apply plugin statement for views-json if it was previously present
apply plugin: 'views-json'
// ... Other configurations and dependencies
By using the buildSrc
folder, developers can separate buildscript dependencies and custom plugin configurations from the main build.gradle
file. This leads to a cleaner and more concise build script, which is easier to maintain and understand. Additionally, the buildSrc
approach encourages modularity, as build logic and custom plugins can be centralized and shared across projects, fostering better collaboration and consistency within development teams.
7. GORM for MongoDB Sync Driver:
The GORM for MongoDB is updated to support the latest mongodb-driver-sync. If you are using GORM for MongoDB and making use of specific MongoDB Driver or low-level Mongo API features, consider checking the Upgrading to the 4.0 Driver guide.
This update ensures seamless integration with MongoDB, access to new features, and improved performance while interacting with your MongoDB database.
8. Asset Pipeline Plugin:
In Grails 6, there is an update to the Asset Pipeline Plugin, which is now version 4.3.0. The Asset Pipeline Plugin is a crucial component in Grails applications, responsible for managing frontend assets like stylesheets, JavaScript files, and images. The update to version 4.3.0 brings several improvements and new features to enhance the management and processing of frontend assets in your Grails projects.
The asset-pipeline plugin 4.3.0 offers new features for managing and processing your frontend assets, ensuring they are efficiently bundled and served to your users.
9. Spring 5.3:
Grails 6 is built on Spring 5.3.27. If your project uses Spring-specific features, refer to the Upgrading to Spring 5.3 guide.
Spring 5.3 introduces enhancements and fixes to the Spring framework, providing you with the latest improvements in dependency injection, web frameworks, and other Spring-related functionalities.
10. Spring Boot 2.7:
Grails 6 updates to Spring Boot 2.7. For more information, consult the Spring Boot 2.7 Release Notes
Spring Boot 2.7 comes with new features, performance enhancements, and compatibility improvements, making it a solid foundation for your Grails application.
11. Micronaut 3.9.3:
Grails 6 is shipped with Micronaut 3.9.3. If you are using specific Micronaut features, refer to the Upgrading to Micronaut 3.x guide.
Micronaut 3.9.3 brings new capabilities, improvements, and bug fixes, empowering your application with a powerful and lightweight microservices framework.
12. Micronaut for Spring 4.5.1:
Grails 6 is updated to use Micronaut for Spring 4.5.1. For more information, check out the release notes.
Micronaut for Spring 4.5.1 provides seamless integration between Micronaut and Spring, allowing you to leverage the strengths of both frameworks in your Grails project.
3.2 Upgrading from Grails 4 to Grails 5
Bump up Grails Version
You will need to upgrade your Grails version defined in gradle.properties
as:
...
grailsVersion=5.2.0
...
Apache Groovy 3.0.7
Grails 5.1.1 provide support for Groovy 3. We would recommend you to please check the Release notes for Groovy 3 to update your application in case you are using a specific feature which might not work in Groovy 3.
Define groovyVersion in gradle.properties
to force the application to use Groovy 3.
Grails 5.1 app’s gradle.properties
...
groovyVersion=3.0.7
...
Bump up GORM Version
If you were using GORM, you will need to update the version defined in gradle.properties
as:
...
gormVersion=7.2.0
...
Bump up gradle version
Grails 5.2.x uses gradle 7.2
...
distributionUrl=https\://services.gradle.org/distributions/gradle-7.2-bin.zip
...
Also you can run this command
./gradlew wrapper --gradle-version 7.2
GORM for MonogDB Sync Driver
The GORM for MongoDB is updated to support latest mongodb-driver-sync. If you are using GORM for MongoDB and doing something specific to MongoDB Driver or low level Mongo API then you might want to take a look at Upgrading to the 4.0 Driver
Bump up Asset Pipeline plugin version
The previous version of asset-pipeline is not supported with Grails 5.0 as it is compiled with a version of Groovy which is binary incompatible with Groovy 3. So, please update the plugin version to 3.2.4.
Disabled StringCharArrayAccessor by default
The previous version of Grails use the StringCharArrayAccessor
which is enabled by default and provides optimized access to java.lang.String
internals. In Grails 5.0 it is disabled by default but you can enable it by setting a system property with name stringchararrayaccessor.disabled
and value false
.
Enabling StringCharArrayAccessor would show IllegalReflectiveAccess warnings as it uses reflection to do the optimizations. |
Changes in profile.yml and feature.yml files in Grails Profiles
The format of how dependencies are defined in features and profiles has been changed. See the section on Application Profiles for more information.
Deprecation of dot navigation of Grails configuration
In order to reduce complexity, improve performance, and increase maintainability, accessing configuration through dot notation (config.a.b.c) has been deprecated. This functionality will be removed in a future release.
Also, you would see a warning message if you are accessing configuration through the dot notation.
The recommended way to access configuration is:
grailsApplication.config.getProperty("hola", String.class)
Deprecated Classes
Spring 5.3
Grails 5.0.0.RC1 is built on Spring 5.3.2 See the Upgrading to Spring 5.3 if you are using Spring specific features.
Spring Boot 2.4
Grails 5.1.1 updates to Spring Boot 2.6. Please check Spring Boot 2.6 Release Notes for more information.
Micronaut 3.2.0
Grails 5.1.1 is shipped with Micronaut 3.2.0. Please check the Upgrading to Micronaut 3.x if you are using a specific feature.
Micronaut for Spring 4.0.1
Grails 5.1.1 is updated to Micronaut for Spring 4.0.1, please check out release notes for more information.
Gradle 7.x
Compile dependency configuration as well as others have been removed from Gradle 7.x. In previous version they were deprecated.
Replace configurations:
...
compile -> implementation
testCompile -> testImplementation
runtime -> runtimeOnly
...
More information in Gradle upgrade docs Gradle upgrade docs |
Plugins in multi-project setup
If you have grails plugins as part of multi-project builds you should also replace the compile
with implementation
configuration.
Additionally if your main application relied on the dependencies declared by the plugin you need to apply further changes.
To make the dependencies available again you have to declare them with api
configuration. You also have to apply the java-library
gradle plugin in your plugin project.
More information gradle java-library-plugin |
3.3 Upgrading from Grails 3.3.x to Grails 4
Bump up Grails Version
You will need to upgrade your Grails version defined in gradle.properties
.
Grails 3 app’s gradle.properties
...
grailsVersion=3.3.8
...
Grails 4 app’s gradle.properties
...
grailsVersion=4.0.4
...
Bump up GORM Version
If you were using GORM, you will need to update the version defined in gradle.properties
.
Grails 3 app’s gradle.properties
...
gormVersion=6.1.10.RELEASE
...
Grails 4 app’s gradle.properties
...
gormVersion=7.0.4
...
Move GORM DSL Entries to runtime.groovy
GORM DSL entries should be move to runtime.groovy
. For instance, using following GORM configuration in the application.groovy
is not supported and will break the application:
grails.gorm.default.mapping = {
id generator: 'identity'
}
Spring 5 and Spring Boot 2.1
Grails 4.0 is built on Spring 5 and Spring Boot 2.1. See the migration guide and release notes if you are using Spring specific features.
Hibernate 5.4 and GORM 7.x
Grails 4.x supports a minimum version of Hibernate 5.4 and GORM 7.x. Several changes have been made to GORM to support the newer version of Hibernate and simplify GORM itself.
The details of these changes are covered in the GORM upgrade documentation.
Spring Boot 2.1 Actuator
Please check the Spring Boot Actuator documentation since it has changed substantially from Spring Boot 1.5 the version Grails 3.x used.
If you had configuration such as:
endpoints:
enabled: false
jmx:
enabled: true
unique-names: true
replace it with:
spring:
jmx:
unique-names: true
management:
endpoints:
enabled-by-default: false
Spring Boot Developer Tools and Spring Loaded
Previous versions of Grails used a reloading agent called Spring Loaded. Since this library is no longer maintained and does not support Java 11 support for Spring Loaded has been removed.
As a replacement, Grails 4 applications include Spring Boot Developer Tools dependencies in the build.gradle
build script. If you are migrating a Grails 3.x app, please include the following set of dependencies:
.
..
...
configurations {
developmentOnly
runtimeClasspath {
extendsFrom developmentOnly
}
}
dependencies {
developmentOnly("org.springframework.boot:spring-boot-devtools")
...
..
}
...
..
.
Also you should configure the necessary excludes for Spring Developer Tools in application.yml
:
spring:
devtools:
restart:
exclude:
- grails-app/views/**
- grails-app/i18n/**
- grails-app/conf/**
The above configuration prevents the server from restarting when views or message bundles are changed.
You can use Spring Developer Tools in combination with a browser extension such as the Chrome LiveReload extension to get automatic browser refresh when you change anything in your Grails application. |
Spring Boot Gradle Plugin Changes
Grails 4 is built on top of Spring Boot 2.1. Grails 3 apps were built on top of Spring Boot 1.x.
Your Grails 3 app’s build.gradle
may have such configuration:
bootRun {
addResources = true
...
}
Grails 4 apps are built on top of Spring Boot 2.1. Starting from Spring Boot 2.0, the addResources
property no longer exists. Instead, you need to set the sourceResources property to the source set that you want to use. Typically that’s sourceSets.main
. This is described in the Spring Boot Gradle plugin’s documentation.
Your Grails 4 app’s build.gradle
can be configured:
bootRun {
sourceResources sourceSets.main
...
}
Building executable jars for Grails Plugins
The bootRepackage task has been replaced with bootJar and bootWar tasks for building executable jars and wars respectively. Both tasks extend their equivalent standard Gradle jar or war task, giving you access to all of the usual configuration options and behaviour.
If you had configuration such as:
// enable if you wish to package this plugin as a standalone application
bootRepackage.enabled = false
replace it with:
// enable if you wish to package this plugin as a standalone application
bootJar.enabled = false
Upgrading to Gradle 5
Grails 3 apps by default used Gradle 3.5. Grails 4 apps use Gradle 5.
To upgrade to Gradle 5 execute:
./gradlew wrapper --gradle-version 5.0
Due to changes in Gradle 5, transitive dependencies are no longer resolved for plugins. If your project makes use of a plugin that has transitive dependencies, you will need to add those explicitly to your build.gradle
file.
If you customized your app’s build, other migrations may be necessary. Please check Gradle Upgrading your build documentation. Especially notice, that default Gradle daemon now starts with 512MB of heap instead of 1GB. Please check Default memory settings changed documentation.
Groovy language update to 2.5.6
Keep in mind, that with grails 4.0.x there is a minor groovy language upgrade (e.g. 3.3.9. used groovy 2.4.x), which requires a couple of changes, that are immediately obvious when trying to compile your source code. However there are also issues with changed implementations of core linkedlist functions! Check an overview of the breaking changes here: Breaking changes of Groovy 2.5
Removed date helper functions
Most common issue is that date util functions have been moved to individual project, e.g new Date().format("ddMMyyyy") no longer works without adding:
dependencies {
implementation "org.codehaus.groovy:groovy-dateutil:3.0.4"
}
Changed linked list method implementations
Check whether you are using the groovy version of linkedlist implementations:
-
[].pop()
- will no longer remove the last, but the first element of the list. Replace it with[].removeLast()
is recommended. -
[].push(..)
- will no longer add to the end, but to the beginning of the list. Replace it with[].add(..)
is recommended.
H2 Web Console
Spring Boot 2.1 includes native support for the H2 database web console. Since this is already included in Spring Boot the equivalent feature has been removed from Grails. The H2 console is therefore now available at /h2-console
instead of the previous URI of /dbconsole
. See Using H2’s Web Console in the Spring Boot documentation for more information.
Upgrade Hibernate
If you were using GORM for Hibernate implementation in your Grails 3 app, you will need to upgrade to Hibernate 5.4.
A Grails 3 build.gradle
such as:
dependencies {
...
implementation "org.grails.plugins:hibernate5"
implementation "org.hibernate:hibernate-core:5.1.5.Final"
}
will be in Grails 4:
dependencies {
...
implementation "org.grails.plugins:hibernate5"
implementation "org.hibernate:hibernate-core:5.4.0.Final"
}
Migrating to Geb 2.3
Geb 1.1.x (a JDK 1.7 compatible version) was the version shipped by default with Grails 3. Grails 4 is no longer compatible with Java 1.7. You should migrate to Geb 2.3.
In Grails 3, if your build.gradle looks like:
dependencies {
testCompile "org.grails.plugins:geb:1.1.2"
testRuntime "org.seleniumhq.selenium:selenium-htmlunit-driver:2.47.1"
testRuntime "net.sourceforge.htmlunit:htmlunit:2.18"
}
In Grails 4, you should replace it with:
buildscript {
repositories {
...
}
dependencies {
...
classpath "gradle.plugin.com.energizedwork.webdriver-binaries:webdriver-binaries-gradle-plugin:$webdriverBinariesVersion" (1)
}
}
...
..
repositories {
...
}
apply plugin:"idea"
...
...
apply plugin:"com.energizedwork.webdriver-binaries" (1)
dependencies {
...
testCompile "org.grails.plugins:geb" (4)
testRuntime "org.seleniumhq.selenium:selenium-chrome-driver:$seleniumVersion" (5)
testRuntime "org.seleniumhq.selenium:selenium-firefox-driver:$seleniumVersion" (5)
testRuntime "org.seleniumhq.selenium:selenium-safari-driver:$seleniumSafariDriverVersion" (5)
testCompile "org.seleniumhq.selenium:selenium-remote-driver:$seleniumVersion" (5)
testCompile "org.seleniumhq.selenium:selenium-api:$seleniumVersion" (5)
testCompile "org.seleniumhq.selenium:selenium-support:$seleniumVersion" (5)
}
webdriverBinaries {
chromedriver "$chromeDriverVersion" (2)
geckodriver "$geckodriverVersion" (3)
}
tasks.withType(Test) {
systemProperty "geb.env", System.getProperty('geb.env')
systemProperty "geb.build.reportsDir", reporting.file("geb/integrationTest")
systemProperty "webdriver.chrome.driver", System.getProperty('webdriver.chrome.driver')
systemProperty "webdriver.gecko.driver", System.getProperty('webdriver.gecko.driver')
}
gebVersion=2.3
seleniumVersion=3.12.0
webdriverBinariesVersion=1.4
hibernateCoreVersion=5.1.5.Final
chromeDriverVersion=2.44 (2)
geckodriverVersion=0.23.0 (3)
seleniumSafariDriverVersion=3.14.0
1 | Includes Webdriver binaries Gradle plugin. |
2 | Set the appropriate Webdriver for Chrome version. |
3 | Set the appropriate Webdriver for Firefox version. |
4 | Includes the Grails Geb Plugin dependency which has a transitive dependency to geb-spock . This is the dependency necessary to work with Geb and Spock. |
5 | Selenium and different driver dependencies. |
Create also a Geb Configuration file at src/integration-test/resources/GebConfig.groovy
.
import org.openqa.selenium.chrome.ChromeDriver
import org.openqa.selenium.chrome.ChromeOptions
import org.openqa.selenium.firefox.FirefoxDriver
import org.openqa.selenium.firefox.FirefoxOptions
import org.openqa.selenium.safari.SafariDriver
environments {
// You need to configure in Safari -> Develop -> Allowed Remote Automation
safari {
driver = { new SafariDriver() }
}
// run via “./gradlew -Dgeb.env=chrome iT”
chrome {
driver = { new ChromeDriver() }
}
// run via “./gradlew -Dgeb.env=chromeHeadless iT”
chromeHeadless {
driver = {
ChromeOptions o = new ChromeOptions()
o.addArguments('headless')
new ChromeDriver(o)
}
}
// run via “./gradlew -Dgeb.env=firefoxHeadless iT”
firefoxHeadless {
driver = {
FirefoxOptions o = new FirefoxOptions()
o.addArguments('-headless')
new FirefoxDriver(o)
}
}
// run via “./gradlew -Dgeb.env=firefox iT”
firefox {
driver = { new FirefoxDriver() }
}
}
Deprecated classes
The following classes, which were deprecated in Grails 3.x, have been removed in Grails 4. Please, check the list below to find a suitable replacement:
Removed Class |
Alternative |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Use traits instead. |
|
|
|
|
|
|
|
Use the |
|
|
|
|
|
Use the |
|
|
|
|
|
Handled by |
|
Use |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Replaced by newer version of commons-validation |
|
Replaced by newer version of commons-validation |
|
Replaced by newer version of commons-validation |
|
Replaced by newer version of commons-validation |
|
Replaced by newer version of commons-validation |
|
|
Grails-Java8
For those who have added a dependency on the grails-java8
plugin, all you should need to do is simply remove the dependency. All of the classes in the plugin have been moved out to their respective projects.
Profiles Deprecation
A few of the profiles supported in Grails 3.x will no longer be maintained going forward and as a result it is no longer possible to create applications when them in the shorthand form. When upgrading existing projects, it will be necessary to supply the version for these profiles.
-
org.grails.profiles:angularjs
→org.grails.profiles:angularjs:1.1.2
-
org.grails.profiles:webpack
→org.grails.profiles:webpack:1.1.6
-
org.grails.profiles:react-webpack
→org.grails.profiles:react-webpack:1.0.8
Scheduled Methods
In Grails 3 no configuration or additional changes were necessary to use the Spring @Scheduled
annotation. In Grails 4 you must apply the @EnableScheduling
annotation to your application class in order for scheduling to work.