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 <https://meet.google.com/her-tjpt-xmf>
Notes for this week follow:
- grails-melody-plugin is moving from the grails Github organization to
grails-plugin organization
- we intend to update it for Grails 7 in the coming weeks
- We have continued to receive feedback about plugins not being updated
from Grails 7. A recent example of this is:
https://github.com/apache/grails-core/issues/14123
- to facilitate the adoption of Grails 7 & to maintain our future,
where possible, we will try to take over abandoned plugins by moving them
to the grails-plugins organization
- We discussed the Gradle Develocity Plugin:
- Enumerating which versions are supported with which develocity
instance.
- ge.apache.org is at version 2024.2.7 (ge.grails.org is at
version 2025.1)
- Plugin version 3.19.x is compatible with 2024.3 or later
- Plugin version 3.18.x is compatible with 2024.2 or later.
- (Plugin version 4.0.0 released, compatible with 2025.1 or later.)
- Apache provides 2 instances: ge.apache.org and develocity.apache.org
- Infrastructure has suggested we use develocity.apache.org or switch
to our own instance.
- We decided to continue to use ge.grails.org due to the discovery
that the develocity plugin version needs to match
- Current Apache Build status
- We discussed the overall build statuses across all of our apache
repos & when we will have full snapshot publishing.
- grails-core, grails-views, grails-data-mapping, and downstream
projects have all been published with apache coordinates.
- These projects do not have successful functional tests due to
other blockers (see below)
- We are currently blocked on the asset pipeline being updated since
its coordinates force duplicate.jars.
- We hope to publish that this weekend, and then we can have an
end-to-end snapshot release.
- Third party actions preventing Builds from running
- Apache is switching to requiring a commit hash for security
- Mattias has updated mongo & redis plugins so that they use a
docker file as a service instead of a github action
- The last remaining build blocker is we do not have the ability to
trigger workflows across GitHub actions. We are working with
infrastructure to restore this functionality so we can progress.
- Publishing Pre-Apache versions of Grails
- There have been significant contributions to grails-geb prior to
the Apache merge. We attempted to wrap these up prior to the move, but
were unsuccessful. There is a desire to publish these contributions so
they are compatible with Grails 6.
- The current solution is to build this locally on a developer
machine and then push it out to the old grails repo for Grails
6.x versions.
- Mattias will take this path for Grails-geb
- grails-cache vote
- The vote for grails-cache to be merged into core has passed. We
will perform this merge the week of 4/14
- grails-gradle-plugin & grails-views merge
- One of the issues found by the coordinate change is just how
coupled the views project is still coupled to core.
- We enumerated the benefits of merging these repositories. Some are
listed here:
- reduce release times (we discussed just how long these have
taken in the past and how each repository reduction has sped
up releases)
- we can enforce dependency separations when they're in the same
repo under the same build system. This means we can decouple easier.
- reduced maintenance burden on having multiple builds
- a common build can have code styles & code analysis applied.
previously some of these were only applied in grails-core
- refactoring is made easier
- The intent is to have grails-gsp & grails-data-mapping to be
able to be separate from a Grails application in the long run.
- previously, prior committers have taken the passing of tests in
grails-core to mean the change is done. We have had
downstream projects
break often from these contributions and if the downstream
projects had
been run against the change, the original contributor could have fixed
these instead of the grails-core developers.
- the ability to have all tests run, in an end-to-end fashion,
will significantly improve our quality and ensure changes
that break grails
will be discovered at PR time instead of later in the
development process.
- We decided on starting a vote thread to merge them after
reviewing the current discussion thread.
- grails-data-mapping merge
- We discussed merging grails-data-mapping. The general consensus
seems to be in favor, but everyone is worried about the impact on build
times.
- Before we open a vote thread, we want to reach out to ASF
infrastructure on possibly having faster build runners.
- We know if we had private / self hosted build runners the build
times would be a non-issue.
- grails-doc merge to core
- We proposed merging the documentation in grails-doc to
grails-core. We would not merge the repository since the repository's
gh-pages branch would continue to host the grails-documentation.
- project version updates
- Some of the merged projects have higher versions than of grails.
- Given that we are changing coordinates, this is our chance to "fix"
those versions to be the same.
- We decided to move to using a maximum project version that
matches the grails version.
- For example, grails-cache will go from 9 to 7.
- Projects with lower versions than 7, will remain on the lower
version unless they are migrated to the grails-core repository.
- best practices for grails-plugins
- the coordinate change has revealed just how many grails libraries
are being transitively included by using gradle scopes such as
'implementation'
- A grails plugin is intended to always be included in a grails
application, and thus we should encourage plugins to use provided scopes
such as compileOnly to limit the need to update plugins in the future.
- we decided to open
https://github.com/apache/grails-core/issues/14129 to address this
long term
- reminder: the meeting now alternates between 2 times.
-
https://www.worldtimebuddy.com/?qm=1&lid=8,6,5,12,30,1819729,2207259&h=8&date=2025-4-16&sln=14-15&hf=1
- then early time the following
-
https://www.worldtimebuddy.com/?qm=1&lid=8,6,5,12,30,1819729,2207259&h=8&date=2025-4-23&sln=7-8&hf=1
- rotates each week, with 1 meeting per week
-James
