Hi Everyone, We gained access to all of the needed credentials in GitHub this past week. I'm happy to report that I've finished the automation steps (up to voting). It is now feasible to hold a vote on the M4 if we wanted. All of the detailed information is documented in the RELEASE.md in grails-core. At a high level, here's what's been done:
1. Per James Fredley's previous discussion grails-core & grails-forge will always release together. This is important because of how our CLI's work and the need for the delegating CLI to call either shell or forge. 2. The grails-github-actions have been tested end-to-end (release testing was missing previously) & any needed fixes have been applied. 3. The grails publish plugin & associated applications were updated for the new signing mechanism. Note: this mechanism uses the local gpg command because a passphrase is not provided for our private key. This does mean it takes longer to build / sign our artifacts. 4. grails-core can now build and deploy to a staging repository 5. grails-forge can now build and deploy to a staging repository 6. a source distribution can now be generated after grails-core & grails-forge are staged. 7. binary distributions (wrapper & the cli's) can now be generated after grails-core & grails-forge are staged. 8. Verification of the grails-core jar files, the grails-forge jar files, the source distribution, the wrapper binary distribution, the CLI binary distribution, & that the build is reproducible has been fully automated. 9. In the event we need to rebuild, we can now drop the staging repositories and recreate the releases. Here's what's still outstanding: * More reproducible Issues: 1. There is an issue verifying the build across platforms - the mac build had javadoc where it picked the wrong class (ConstraintsEvaluator) for method arguments. It appears this is only a problem when duplicate classes exist across java & groovy in different packages. (This needs further investigation, but it's not a blocker for this release since we can use a container to verify the artifacts) 2. While we fixed the reproducible differences when testing on the same platform, this process found more differences when testing across platforms. I've fixed all of the issues that we have control of, but there are 2 groovy issues I've found. a. `@Delegate` reorders methods in the scaffolding project. I've opened https://github.com/apache/groovy/pull/2245 to fix this. b. `@DelegatesTo` reorders its attributes - this impact is most seen on the GormEntity trait due to its withCriteria() method. I've fixed this in groovy here: https://github.com/jdaugherty/groovy/tree/delegates-to-fix, but I'm not sure if it's the "right" fix. I need Paul's guidance on this one. Since both of these are explainable, neither of these changes are "needed" for the M4. * Our SVN credentials to upload the artifacts are not working in GitHub Actions. I've opened https://issues.apache.org/jira/browse/INFRA-26876 to address this. We can workaround this issue for the release by manually staging the artifacts. * Our release process is spread across several different GitHub workflows - instead of being in one. We can't put them in one until we have a way to "delay" running those next steps. We've previously accomplished this via the usage of github 'environments'. In the coming week, I intend to open an infrastructure ticket to get these environments created, and then I'll collapse the workflows so there's one release workflow in `grails-core` and one in `grails-forge`. * Paul did an early review of our artifacts and found several compliance issues with ASF policy. I think we've addressed all of the found issues, but we need help from experienced Apache members! We need people to check the source distribution, wrapper binary distribution, and cli binary distribution to see if they meet Apache's policies. Currently, these artifacts aren't staged to SVN for a vote, but they can be downloaded from the M4 pre-release on Github. I hope to follow-up / each out to several members for their assistance on this. * We still don't have our website published or updated to the ASF site. Søren recently agreed to take a look at the website. I'm hoping he has time to help us here. * Mattias has begun work on the Headers & License updates for Grails Spring Security. When this work is complete, we'll need to do something similar to `grails-core` so we can publish the Grails Spring Security plugins. My assumption is we'll hold the Grails 7.0.0-M4 vote prior to this work finishing and have a separate vote for the security plugins. Overall, we could hold a vote and manually perform the remaining steps. Other than getting some people to take an early look at our artifacts for Apache compliance, I can't think of a reason to further delay the 7.0.0-M4 release. What are people's thoughts on this? Any concerns? Regards, James On Mon, May 19, 2025 at 10:57 AM James Fredley <jamesfred...@apache.org> wrote: > We are very close and it has taken a gargantuan amount of effort to > prepare for the first Apache Grails milestone. > > I agreed with the list under "the following needs completed" and think > these two items should be part of that list, for clarification. > > # grails-forge will be staged for release, voted on and released at the > same time as grails-core. now required for grails-wrapper, in addition > grails-forge-cli (now part of combined shell distribution to SDKman) and > start.grails.org > # New grails-quartz and grails-redis plugin milestones will be releases, > after grails-core. These two plus grails-spring-security, are the three > remaining non-grails-core plugins that moved to ASF. > > Under "some other outstanding item", I do not believe we need to use > 'Apache Grails' in each location that currently says 'Grails'. See Groovy > Documentation: https://groovy-lang.org/single-page-documentation.html. > That saves us some time. > > https://github.com/apache/grails-static-website/issues - I am glad to > help on the website, I just want to fully understand the end state and > publishing process so we can complete it in one pass and not have to rework > it multiple times. > > James > > On 2025/05/17 18:57:10 James Daugherty wrote: > > Hi Everyone, > > > > In the weekly meeting we briefly discussed the outstanding items to > release > > the first Apache milestone: > > https://lists.apache.org/thread/hm3v6ooqqchms81tljk8h2vpvtj1qfcf > > > > I think this discussion merits its own mailing list thread and I'm > > interested to hear everyone's thoughts on the current plans. From our > > meeting: we think the current code line now is functional end-to-end. We > > now need to determine what should be finished so we can release 7.0.0-M4. > > From my notes, the following needs completed to proceed with an Apache > > Grails milestone release: > > > > # We will likely wait for Groovy 4.0.27 with Paul's reproducibility > fixes. > > # (assigned to James D) We need to create a script used to verify our > > build (so we can satisfy Security's requirements) > > # (assigned to James D) 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. > > # (assigned to James D) We need to have GitHub only stage, not > > "release". This requires minor build updates on our side. We intend > > to manually release the jars to maven central as part of our voting > > workflow. > > # (assigned to Mattias) spring-security has to be released & headers > added. > > > > I think we have some other outstanding items too, but it's not clear to > me > > if they need to be done to perform a release: > > # We need to rebrand "Grails" to "Apache Grails" in our documentation. > > # We need to remove references to the Grails Foundation on the website > > # We need to deploy the grails.apache.org website. > > > > > > Here's my first attempt at a summary of 7.0.0-M4: > > > > Apache Grails 7.0.0-M4 is the first release for Grails under the Apache > > Software Foundation (ASF). This release focuses first on meeting the > > requirements of the ASF & improving the developer experience of Grails > > itself & Grails Applications. As part of this transition, the developers > > moved to a mono repository, reworked the way the various Grails CLIs > work, > > modernized its build system, modernized the various Grails Gradle Tasks, > > modernized the various Grails Gradle Plugins, worked towards reproducible > > builds, added license headers to our source code, and changed the maven > > coordinates of all Grails Artifacts. > > > > Here is the detailed list since 7.0.0-M3: > > * PR #14750 - support non-persistent super classes for @Autotimestamp > > * Issue #14745 - remove deprecated doc method on Grails Plugins > > * Issue #14745 - remove duplicate grails.factories & grails-plugin.xml > > files now that AST generation is working correctly > > * Issue #14745 - switch to Spring Boot 3.5.0-RC1 with Spring Framework > > 6.2.7 due to bug ( > > https://github.com/spring-projects/spring-framework/issues/34796) > > * Issue #14745 - change the grails-gradle-model to export Groovy 3 due to > > Gradle Task isolation in later versions of Gradle > > * Issue #14745 - rework the FindMainTask to correctly set the main > > Application class on BootWar, BootJar, & BootRun > > * Issue # 14745 - remove org.grails.plugins.CodecGrailsPlugin; > > use org.grails.plugins.codecs.CodecsGrailsPlugin instead > > * Issue # 14745 - remove the remaining pathingJar task functions > > * Issue # 14745 - fix a databinding scenario in DataBindingUtils to > lookup > > a domain object > > * PR #14749 - retire Mongo 5.0 & 6.0 test pipelines since those versions > > are end of support > > * PR #14746 - switch to asset-pipeline-gradle to 5.0.9 > > * PR #14743 - remove redundant buildScript from test projects > > * Issue #14706 - rework grailsw to be usable indepedendently of SDKMAN > > installs > > * Issue #14706 - rework grails-shell-cli to be usable independently of > > SDKMAN installs > > * Issue #14706 - rework the command cli to support a grailsw that can > > self-update either forge or legacy shell cli > > * Issue #14706 - distribute a delegating CLI that can call either forge > or > > the legacy shell cli > > * Issue #14706 - rework the legacy shell cli to correctly find profiles > > * Issue #14706 - rework both grailsw & grails-shell-cli to be testable > > outside of releases > > * Issue #14679 - generate reproducible groovydoc jars > > * Issue #14679 - fix profile compilation to generate reproducible jars > > * Issue #14679 - ensure groovydoc is used instead of javadoc for > > documentation jars > > * PR #14709 - switch to Gradle 8.14 > > * PR #14678 - add support for external config locations > > * Refactor grails into a mono repo (grails-views, gsp, data mapping, geb, > > etc are all merged into core now) > > * As part of the mono repo transition, several Deprecated classes were > > removed from the views project; see the upgrade guide for the details. > > * Issue #14679 - refactor grails build to be parallel & lazy > > * Issue #14679 - change all Grails gradle tasks to support Caching where > > appropriate and support lazy style configuration > > * Issue #14679 - Redesign the Grails Data TCK to support modern versions > of > > Java > > * Issue #14679 - Support consistent property dates in generated property > > files when SOURCE_DATE_EPOCH is set > > * Issue #14679 - Make grails.factories generation reproducible > > * Issue #14679 - Refactor Grails AST Transformations to take advantage of > > Groovy's TransformWithPriority and enforce transforms always run in the > > order defined by the class `GroovyTransformOrder` > > * Issue #14679 - Remove manifest attributes that could vary on the Grails > > jars (Built-By, Created-By etc) > > * Issue #14679 - Fix sourcejar creation to not contain duplicates > > * Issue #14679 - Fix javadoc jars to be generated based on groovydoc & to > > not contain duplicates > > * Issue #14679 - Change AST transforms to be reproducible by adopting > > determined ordering collections > > * Issue #14679 - Configure Grails jars per Gradle's reproducibility > > requirements (fixed permissions, reproducible file order, etc) > > * Issue #13850 - introduce `grails-common` to share common code between > > Grails Data Mapping & Grails-Core > > * Issue #14679 - add scripts to confirm reproducibility of Grails; > > currently 14 of 290 jars are reproducible > > * Issue #14679 - make TagLib lookups reproducible > > * PR# 14671 - switch to webjars for test css/js assets instead of checked > > in files > > * The Grails Gradle plugin had a bug that caused plugin resolution issues > > that was fixed after the last milestone. > > * Rework the grails bom to generate valid Gradle modules, be easier to > > maintain, and valid pom files. Enhance the documentation process to > parse > > the bom & generate the published versions in the grails doc. > > > > > > And in addition to all of this: > > * We changed all coordinates of Grails to be org.apache.grails based. See > > https://github.com/apache/grails-core/blob/7.0.x/RENAME.md for how we > > mapped these libraries. There is also a script documented in the upgrade > > guide to assist in upgrading. > > * Significant test fixes > > * Significant documentation updates & changes > > * Addition of license headers to Grails Source > > * Addition of NOTICE to Grails Source > > * Created https://repo.grails.org/grails/restricted/ to replace > > https://repo.grails.org/grails/core longer term. This virtual repo's > scope > > is significantly reduced to help reduce the chance of using outdated > > libraries. > > > > > > I'm hoping this recap is a starting point for the release notes of > > 7.0.0-M4. I'm sure I've missed something too. What are people's > thoughts > > on the nexts steps and these notes? > > > > -James > > >
