Fails with grails 5.0.1 gradle 7.2 and groovy 3.0.7
Opened this issue · 8 comments
gradle sync fails on lines like 'bootstrap'('4.3.1').
Created new grails 5.0.1 project and added client-dependencies. Added this configuration:
clientDependencies { yarn { 'bootstrap'('4.3.1') } }
I have attached the output from gradle sync in Idea and the build.gradle file.
Seeing the same problem as above.
This seems to be some kind of Groovy "unwrapping" problem when it takes Java String functions and shims them into Groovy's own support functions.
SimpleDependency.groovy:20 references String.matches. However, the signature of String.matches actually changes from Groovy 2.x to Groovy 3.x, based on the StringGroovyMethods class.
Latest (3.x) defines .matches(CharSequence self, Pattern pattern), which seems to be overriding the default signature for Java String.matches(Pattern pattern).
However, 2.4.7 has a Deprecated (and, in 3.x, removed) method: matches(String self, Pattern pattern), as well as matches(CharSequence self, Pattern pattern).
My assumption, based on this info and the error message, is that for some reason the compiler here allows for the signature override when anyString.matches(anyPattern) is called by converting it into some form of StringGroovyMethods.matches(anyString, anyPattern); however, the only available method in 3.x is StringGroovyMethods.matches(anyCharSequence, anyPattern), hence the NoSuchErrorMethod we're seeing:
Caused by: java.lang.NoSuchMethodError: org.codehaus.groovy.runtime.StringGroovyMethods.matches(Ljava/lang/String;Ljava/util/regex/Pattern;)Z
This is a little confusing, because a String should be matched by CharSequence and I don't see why it would not be.
I have forked, updated to work with Gradle 7.x, and pushed as a new plugin. Thought you might want to know: https://github.com/piper-magnetic/client-dependencies-gradle
This change required no actual code change, only configuration change. It seems like it may well be that this project is just not "configured" to work with Groovy 3, which means it wont work with Gradle 7.
@craigburke
I am not aware of the best means by which to merge the two as there is a bit of overhaul needed to get up to 7.x compatibility. If you've got some ideas, let me know so I can perhaps PR in and we can return to the single Gradle plugin.
Just had to do the Grails 5 upgrade and ran into the same issue. Switched to your forked version for now - thank you!
@piper-magnetic Just got around to clone the repo and build. Works like a charm. Have you considered publishing to maven central?
@gorgiev -- glad it panned out!
@yggdrasildy -- haven't ever published anything to maven central, but if it's something that would be of value to you I'd be happy to do so (in order to avoid another split in the build).
I do note that i have left out how to use it in Gradle builds: it can be imported as such:
plugins {
id "com.magnetichq.client-dependencies" version "2.0.0"
}
I will take some time to add this info to the readme as it still reflects the old codebase import logic. It is available from the gradle plugins repo (plugins.gradle.com)
@piper-magnetic thanks for your fork, very helpful. I was wondering: why did you declare the artifact id as client-dependencies-g7 with the g7 suffix? Is this to signal compatibility with Gradle 7 and - with potential future incompatible changes of the Gradle API in mind - so that you can publish new artifacts on new coordinates such as client-dependencies-gX should it become necessary?
Also, I would have rather put this question as an issue on your fork's repository, however issues have been disabled. Would you mind enabling them?
@sebkur -- I have enabled Issues, thanks for pointing that out.
The g7 suffix was added to distinguish the Gradle7 compatibility, but also as this was effectively my first contribution to Gradle plugins and I wanted to make sure that I wasn't going to cause, or run into, conflicts around artifact namespace. I did note some upcoming warnings for Gradle 8 changes so adding a candidate version tag seemed like a good approach to me.
Is there a compelling reason to drop the g7? I'm just wondering why you're asking. Feel free to move this to the piper-magnetic Issues section.