@James Daugherty <jdaughe...@jdresources.net> With all the work you have been and are doing, I am confident that we should move to a vote right away.
Den man. 2. jun. 2025 kl. 18.11 skrev James Fredley <jamesfred...@apache.org >: > 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 > > > > > > > > > > -- Med venlig hilsen, Søren Berg Glasius Hedevej 1, Gl. Rye, 8680 Ry Mobile: +45 40 44 91 88 --- Press ESC once to quit - twice to save the changes.
