Thanks everyone.  Based on this feedback + the PR feedback for the next
steps, I'll start this process and open a vote thread soon.


On Mon, Jun 2, 2025 at 12:20 PM Søren Berg Glasius <soe...@glasius.dk>
wrote:

> @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.
>

Reply via email to