Groovy 4.x Support

[codeconsole]

Feature description

Because Groovy now changed their repo

https://repo1.maven.org/maven2/org/apache/groovy/groovy-all/

You can not simply change grade.properties

groovyVersion=4.0.0

It will result in:

> Could not resolve all files for configuration ':runtimeClasspath'.
   > Could not find org.codehaus.groovy:groovy:4.0.0.

Unfortunately, Grails will not run using Java 17 and Groovy 4 is really the only version at this time that will work with Java 17.

Bonus question: Why has grails not updated to Groovy 3.0.9? The last several releases have all used 3.0.7

[arixmkii]

Seems to be impossible for Grails 5.X, because it will be a breaking change.

Also, you need the same amount of support for Groovy 4.0 in all plugins (including third party) and all libraries or it will lead to a conflicting class path. 🤔 If there is no some special magic in gradle for applying workraound to the whole build.

[codeconsole]

I think all the plugins can be handled by adding an exclude in build.grade that prevents the groovy 3 jar from resolving

[arixmkii]

adding an exclude in build.grade

Not elegant and error prone, but could work. Still would be better to have at least most popular plugins with version bump and keep the workaround for the rest of them.

[osscontributor]

If there is no some special magic in gradle for applying workraound to the whole build.

Gradle does support applying the dependency across the whole build, but I don't think that is the issue. I think the issue is compatability with the version of Groovy in question.

[codeconsole]

Well, the org.codehaus.* packages still exist https://docs.groovy-lang.org/latest/html/gapi/index.html

Perhaps if there are plugins that never upgraded the packages to groovy 3 would be an issue. Legacy package removal https://groovy-lang.org/releasenotes/groovy-4.0.html

A decision will need to be made whether to support JDK 17 with Groovy 3.x or just go straight to Groovy 4.x because there will be situations that require temporary hacks to support JDK 17 which will not be required with Groovy 4.x https://issues.apache.org/jira/browse/GROOVY-10405 https://issues.apache.org/jira/browse/GROOVY-10481

[rainboyan]

Before updating to Groovy 4.0, Grails Core and GORM should be migrate to Groovy 3.0, because some legacy packages have been removed, like groovy.util.XmlSlurper which was still used in module grails-databinding.

We can do this by forcing the project dependencies to be upgraded to Groovy 4,

repositories {
    mavenLocal()
    mavenCentral()
    maven { url "https://repo.grails.org/grails/core" }
}

configurations.all {
    resolutionStrategy.dependencySubstitution {
        substitute(module("org.codehaus.groovy:groovy")).using(module("org.apache.groovy:groovy:4.0.5"))
        substitute(module("org.codehaus.groovy:groovy-ant")).using(module("org.apache.groovy:groovy-ant:4.0.5"))
        substitute(module("org.codehaus.groovy:groovy-json")).using(module("org.apache.groovy:groovy-json:4.0.5"))
        substitute(module("org.codehaus.groovy:groovy-sql")).using(module("org.apache.groovy:groovy-sql:4.0.5"))
        substitute(module("org.codehaus.groovy:groovy-templates")).using(module("org.apache.groovy:groovy-templates:4.0.5"))
        substitute(module("org.codehaus.groovy:groovy-xml")).using(module("org.apache.groovy:groovy-xml:4.0.5"))
    }
}

but this is far from enough. When I went further, I found that there were some errors in the GORM and Hibernate5 plugin after they were upgraded to Groovy 4.

In Hibernate5 plugin: HibernateDatastoreSpringInitializer getBeanDefinitions,

groovy.lang.MissingMethodException: No signature of method: org.grails.datastore.gorm.bootstrap.AbstractDatastoreInitializer.findEventPublisher() is applicable for argument types: (org.springframework.boot.web.servlet.context.AnnotationConfigServletWebServerApplicationContext) values: [org.springframework.boot.web.servlet.context.AnnotationConfigServletWebServerApplicationContext@4c9fd7c2, started on Fri Oct 14 20:47:41 CST 2022, parent: application]
Possible solutions: findEventPublisher(org.springframework.beans.factory.support.BeanDefinitionRegistry)
        at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.unwrap(ScriptBytecodeAdapter.java:72)
        at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodOnSuperN(ScriptBytecodeAdapter.java:148)
        at grails.orm.bootstrap.HibernateDatastoreSpringInitializer.getBeanDefinitions(HibernateDatastoreSpringInitializer.groovy:138)
        at grails.plugin.hibernate.HibernateGrailsPlugin$_doWithSpring_closure1.doCall(HibernateGrailsPlugin.groovy:73)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

and in ServiceTransformation of GORM 7, Opcodes.ACC_PUBLIC of asm not found. There are other breaking changes, I found this: GROOVY-9736 Remove org.objectweb.asm.Opcodes as implemented interface in most (all?) places

I think it's quite possible to use Groovy 4 on the current Grails 5 project. But before we can do that, we have to solve the all the problems.

I spent a lot of time trying to solve these problems, and it turns out that they do work, although there are still some uncertain problems that need to be tested.

[codeconsole]

@rainboyan aren't Grails Core and GORM already Groovy 3?

https://github.com/grails/grails-core/blob/5.2.x/gradle.properties#L14 https://github.com/grails/gorm-hibernate5/blob/7.3.x/gradle.properties#L7 https://github.com/grails/grails-data-mapping/blob/7.3.x/gradle.properties#L25

I can confirm Grails 5 already works with JDK 17

[rainboyan]

Groovy 3 is making changes to allow the codebase to move towards the compliant rules and allow Groovy users to begin the migration process. Groovy 4 is our target version for fully-compliant artifacts but you can start getting your classes ready ahead of time while using Groovy 3.

As part of this change, some classes are moving packages. In a subset of those moved classes, it makes sense for Groovy 3 to have two copies of such classes:

What I mean is that, currently Grails Core and GORM still using some deprecated class having the old package name, not the new class having the new package name. When a new Grails 5 app upgrade to Groovy 4.0, but it would not be working.

IMO, Grails Core and GORM should compile and test passed with Groovy 4, and build target for Groovy 3, so Grails 5 app could using Groovy 3 or 4.

[codeconsole]

Thanks for clarifying. That makes sense.

[codeconsole]

Micronaut Groovy ready for Groovy 4 https://github.com/micronaut-projects/micronaut-groovy/issues/322#event-7558717036

Micronaut Groovy held up until GORM 8 https://github.com/micronaut-projects/micronaut-groovy/pull/414