Thank you for all the hard work getting this ready for the vote on the first Apache Grails Milestone.
I believe we should call a vote as soon as we can. James On 2025/06/01 11:04:21 James Daugherty wrote: > 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 > > > > > >
