We meet every week via a google meeting. The times alternate each week to encourage attendance from multiple time zones. Each week we will provide a summary here to facilitate historical preservation & further discussion. If you would like to join this meeting, you can do so here: https://meet.google.com/her-tjpt-xmf
Notes: 1. We had an update on the shell-cli, forge-cli, and wrapper rewrite. At this point, PRs are open and we have a working solution. Associated PRs & tickets are: # branches https://github.com/apache/grails-forge/tree/wrapper-rewrite https://github.com/apache/grails-core/tree/wrapper-rewrite # PRs https://github.com/apache/grails-forge/pull/575 https://github.com/apache/grails-core/pull/14735 2. James D gave an update on the reproducible builds for grails-core: Progress has been made by Paul to determine the cause of the reordering. There's something about the grails project that causes Class#getMethods to be non-deterministic. Paul is working on changes locally that may resolve this issue. His initial attempt removed another half of the differing jars, but he's working on a more complete solution. 3. As part of the CLI rework, we discussed the reproducibility of grails-forge. Previously, we noted that forge isn't reproducible because of the binaries it generates. We further researched graalvm and have discovered this has been an outstanding goal of graalvm (for 6+ years). Later versions of graalvm are supposedly better, but the problem has not been solved upstream. After switching away from binaries (to jar files), we know that the jar files we publish out of forge are reproducible. 4. James D noted that the UPRADE7.md in grails-core had not been merged into the grails-doc. As part of the CLI rework, a first attempt at this has been made. We still need volunteers to go over the grails-doc project. There's a lot of old information that needs to be updated. 5. A status on the hibernate6 merge branch was given. We reviewed Walter's problem from the mailing list and we noted that it's a limitation of how the TCK is applied - to run a TCK test, you must run one of the associated suite classes (Hibernate6Suite). The status of that branch is the hibernate6 core tests are passing, but the tck tests need more work. It's likely they're broken due to naming strategy changes in Hibernate 6 & dialect changes as part of updates. Finally, James D commented on how some of the dependencies were wrong in build.gradle and were adjusted (jcache location was moved). 6. We discussed the random test failures that are happening in the grails-core builds. This may be due to memory or resource constraints - including too many parallel builds. We think the containers are being stopped unexpectedly, causing the build to fail. We agreed we should try restricting the number of matrixed builds to see if this resolves the issue. 7. We discussed the random test failures on grails-forge. Specifically, GradleSpec -> test buildSrc/build.gradle. We discussed how these failures appear to be cache related. In grails-core we have the e2e gradle tests, and we don't see issues there. James D will try to apply the same changes to forge to see if that resolves the failures or we'll @Ignore and add a ticket for it. 8. We discussed Java 24 unlocking virtual threads for Spring Boot apps. James F opened a PR here: https://github.com/apache/grails-core/pull/14732. We discussed how to proceed with Java 24. We all agreed that we should not list Java 24 as a tested solution (it's too early), but we encouraged people to use it. We debated whether to replace the 23 build with the 24 build or if we should have a 24 specific build. Groovy is testing with 24 & 25, but Grails fails with 25. All of the groovy tests are passing with Java 24, but there are some JDK doc redirection errors. James F is going to further research this over the coming week and we will either merge the previously mentioned PR or we'll create a regularly run 24 build. 9. We discussed the repository configurations that exist across several of the gradle builds in grails-core. We agreed to 1. remove the duplicated build script in grails-test-examples (James F to do this). 2. leave the e2e tests as is since they're meant to test in isolation 3. use the `restricted` repo that James D added so we can easily add future repos. 10. Gradle 9's milestone now includes Groovy 4.0.26. We discussed the possible problems & compared it to Groovy 3 vs 4 when Gradle's groovy mismatched our version. Gradle 9 is on track to release by the end of this quarter. We agreed that it will be targeted for Grails 8 due to the gradle plugin impacts. 11. We discussed the remaining tasks to release an Apache Milestone: # We will likely wait for Groovy 4.0.27 with Paul's reproducibility fixes. # We need the new grailsw integrated into grails forge # We need to create a script used to verify our build (James D to work on this) # We need to create a gradle script to publish the source/jars to the Apache distribution locations. We plan to model it after the groovy-release repo. # We need to have GitHub only stage, not "release". This requires build updates on our side. We intend to manually release the jars to maven central as part of our voting workflow. # CLI rework has to be merged & working. # spring-security has to be released & headers added. # We need to solve the invalid / corrupt jar issue https://github.com/apache/grails-core/issues/14729 12. We reviewed the project board https://github.com/orgs/apache/projects/487/views/2?sliceBy%5Bvalue%5D=grails%3A7.0.0-M4 updating tickets that we think are realistic for the milestone. 13. We discussed Grails.org domain & DNS. James F created https://github.com/apache/grails-core/issues/14731 and needs to setup time with OCI for next steps. 14. We have begun testing Groovy 5 and have found various issues. There is an initial discussion on the spock issues here: https://github.com/spockframework/spock/discussions/2160 We intend to create a grails-core ticket to track these issues & create a build to get a head of this issue so we don't have happen what happened in Grails 7 with Groovy 4. 15. Mattias is working on the Apache License headers for spring security. Other repos will follow after the milestone release. 16. There has been traction on getting IntelliJ to support the new apache coordinates in their Grails plugin. https://youtrack.jetbrains.com/issue/IDEA-372363/ is the tracking ticket. -James
