-
-
Notifications
You must be signed in to change notification settings - Fork 953
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
Comments
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. |
I think all the plugins can be handled by adding an exclude in build.grade that prevents the groovy 3 jar from resolving |
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. |
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. |
Well, the org.codehaus.* packages still exist Perhaps if there are plugins that never upgraded the packages to groovy 3 would be an issue. 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 |
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 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: 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 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 aren't Grails Core and GORM already Groovy 3? https://github.com/grails/grails-core/blob/5.2.x/gradle.properties#L14 I can confirm Grails 5 already works with JDK 17 |
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. |
Thanks for clarifying. That makes sense. |
Micronaut Groovy ready for Groovy 4 Micronaut Groovy held up until GORM 8 |
Is it appropriate to assign this issue to the Grails 7 project? |
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
It will result in:
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
The text was updated successfully, but these errors were encountered: