Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Groovy 4.x Support #12373

Closed
codeconsole opened this issue Feb 5, 2022 · 11 comments
Closed

Groovy 4.x Support #12373

codeconsole opened this issue Feb 5, 2022 · 11 comments

Comments

@codeconsole
Copy link
Contributor

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
Copy link

arixmkii commented Feb 7, 2022

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
Copy link
Contributor Author

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

@arixmkii
Copy link

arixmkii commented Feb 7, 2022

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.

@jeffscottbrown
Copy link
Member

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
Copy link
Contributor Author

codeconsole commented Feb 9, 2022

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
Copy link
Contributor

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.

@rainboyan
Copy link
Contributor

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
Copy link
Contributor Author

Thanks for clarifying. That makes sense.

@codeconsole
Copy link
Contributor Author

Micronaut Groovy ready for Groovy 4
micronaut-projects/micronaut-groovy#322 (comment)

Micronaut Groovy held up until GORM 8
micronaut-projects/micronaut-groovy#414

@jeffscottbrown
Copy link
Member

Is it appropriate to assign this issue to the Grails 7 project?

@jamesfredley jamesfredley closed this as completed by moving to Done in Grails 7 Sep 30, 2024
@jamesfredley jamesfredley moved this to Done in Grails 7 Sep 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Done
Development

No branches or pull requests

6 participants