Hi Carl, Thank you for clarifying! I'm glad the documentation was able to help too.
As for the verification failures, that script attempts to compare each jar file to a locally built copy vs the uploaded copy. We are unfortunately not 100% reproducible yet - but we are close! We produce some 300ish jars, and out of those jars we typically have 4-5 that aren't reproducible. When we spoke with ASF security, the build needs to be verifiable - reproducible is one way for this. The current strategy is to take those 4 jars, extract each matching set, and then compare the decompiled byte code to ensure they're functionality equivalent. FYI: the remaining differences can be explained by the following: 1. https://issues.apache.org/jira/browse/GROOVY-11689 - @Delegate causes method reordering 2. https://issues.apache.org/jira/browse/GROOVY-11715 - @DelegateTo has it's parameters reordered 3. Grails-forge has not updated to groovy 4 so the groovydoc doesn't have the fixes we made in https://issues.apache.org/jira/browse/GROOVY-11674 have not yet been applied Once these are fixed, I am expecting our verification to be clean going forward. -James On 2025/07/16 22:55:38 Carl Marcum wrote: > Hi James, > > I was running the script locally and I had set GRAILS_REPO_URL. > I should have read the whole document before I started because I hadn't > got to the Docker container :) > > Now I've tried it and seemed to go well except for the mention of > verification failed shown below. > Is that typical? > > --- > > FAILURE: Build failed with an exception. > > * What went wrong: > Gradle build daemon disappeared unexpectedly (it may have been killed or > may have crashed) > > * Try: > > Run with --stacktrace option to get the stack trace. > > Run with --info or --debug option to get more log output. > > Run with --scan to get full insights. > > Get more help at https://help.gradle.org. > ❌ Verification failed. ❌ > ❌ Verification failed. ❌ > ✅ Reproducible Build Verified > Be sure to do the following: > ☑️ Set the override repo: 'export > GRAILS_REPO_URL=https://repository.apache.org/content/groups/staging' > ☑️ Run the wrapper ShellApp: cd > /home/groovy/grails-verify/apache-grails-wrapper-7.0.0-M5-incubating-bin/ShellApp > > && ./gradlew bootRun --init-script ~/grails-verify/custom-repos.gradle > ☑️ Run the wrapper ForgeApp: cd > /home/groovy/grails-verify/apache-grails-wrapper-7.0.0-M5-incubating-bin/ForgeApp > > && ./gradlew bootRun --init-script ~/grails-verify/custom-repos.gradle > ☑️ Run the cli ShellApp: cd > /home/groovy/grails-verify/apache-grails-7.0.0-M5-incubating-bin/bin/ShellApp > && ./gradlew bootRun --init-script ~/grails-verify/custom-repos.gradle > ☑️ Run the cli ForgeApp: cd > /home/groovy/grails-verify/apache-grails-7.0.0-M5-incubating-bin/bin/ForgeApp > && ./gradlew bootRun --init-script ~/grails-verify/custom-repos.gradle > ☑️ Add the local repos to the application and then run the shell cli > from one of the applications and ensure all commands show as expected - > pay attention to the scaffolding ones since they are dynamically loaded > ✅✅✅ Verification finished, see above instructions for remaining manual > testing. > groovy@6b743c022c7a:~/grails-verify$ > > --- > > I'll continue working through the remaining steps so I have it for next > time. > > BTW, congratulations All on the M5 milestone! > > Best regards, > Carl > > On 7/13/25 12:11 PM, James Daugherty wrote: > > Hi Carl, > > > > First, thank you for taking a look at the release! > > > > Are you running the very script locally on your machine or in the docker > > container command we provide in the RELEASE.md? Also, are you running those > > commands manually or is the verify script? If you're running them > > manually, you need to point at the staging repo so the wrapper downloads > > the file: export > > GRAILS_REPO_URL=https://repository.apache.org/content/groups/staging > > > > Concerning this specific issue, we did discover that the wrapper can fail > > in certain circumstances, specifically around these temporary > > states.https://github.com/apache/grails-core/pull/14896 is the PR that > > fixes it for the next release - I didn't feel it was important enough to > > cancel the release given the scope of changes over the past month (this is > > a milestone so we expect issues like this to be found) & because the issue > > only affects these transitives states / snapshots. > > > > -James > > > > On 2025/07/13 13:46:22 Carl Marcum wrote: > >> Hi All, > >> > >> I was trying to go through the verification using the verify.sh script > >> during the vote. > >> I think I'm missing some setup or something. > >> > >> I was running the verify script from my up-to-date clone of grails-core. > >> > >> /./etc/bin/verify.sh v7.0.0-M5 ~/temp/verify/ > >> > >> and it seems to be failing during the verify-wrapper-distribution.sh > >> section: > >> > >> /./grailsw -t shell create-app ShellApp/ > >> > >> Checking wrapper shell command ... > >> java.lang.ClassNotFoundException: > >> org.apache.grails.cli.DelegatingShellApplication > >> at > >> java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:445) > >> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:593) > >> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:526) > >> at java.base/java.lang.Class.forName0(Native Method) > >> at java.base/java.lang.Class.forName(Class.java:534) > >> at java.base/java.lang.Class.forName(Class.java:513) > >> at grails.init.Start.main(Start.java:74) > >> ❌ Verification failed. ❌ > >> > >> I do currently have M4 installed so I don't know if that has anything to > >> do with it or not. > >> > >> I didn't have a lot of time during the M5 vote to get into it but > >> hopefully I can be ready for future ones. > >> > >> Best regards, > >> > >> Carl > >>
