We meet every week via a google meeting. Each week we will provide a
summary here to facilitate historical preservation & further discussion.
If you would like to join this meeting, please see:
https://calendar.google.com/calendar/r?eid=MGNnc29hYjFvYW1ndjI5ODJiZXRwZGRjbmMgamFtZXNmcmVkbGV5QHRyaXVtcGhpbnRlcmFjdGl2ZS5jb20&ctok=amFtZXNmcmVkbGV5QHRyaXVtcGhpbnRlcmFjdGl2ZS5jb20
Notes for this week follow:
- We have opened the infrastructure ticket to start the repository
moves.
- Work has begun to set up our repository configurations, change the
github actions we use, and restructure the builds to support an Apache
release cycle.
- There will likely be a delay on the repository move, so we may
pre-stage changes to merge once in Apache or start merging them as
convenient.
- I would expect snapshot builds to be significantly broken once
repositories move.
- The end of life policy of Grails was discussed.
- Currently https://endoflife.date/grails exists.
- We need to open a PR to update for grails 5 (no longer active
maintenance & no longer active development)
- We need to open a PR to update grails 6 (active maintenance)
- Maintenance has historically been defined as "receiving security
patches"
- Development has historically been defined as "receiving new
features"
- There was a proposal to have 6 "in maintenance" for a year -
meaning it would receive security patches for a year after 7's release.
- There was a proposal to have 7 "in dev" once released, and we would
follow the spring boot release schedule.
- We plan to follow-up on specifics once we release 7.
- We discussed the recent grails-logging
<https://lists.apache.org/thread/s2539lxmdcbfk2sblzhvjh5ddnjvgm6p>thread:
- Immediately, we agreed:
- Document adding @Slf4j annotation to non-grails artifacts
- Document how to remove the logging behavior
- We discussed some of its current deficiencies:
- https://github.com/grails/grails-core/issues/11000 -
grails-logging doesn't honor dynamic log level changes
-
https://github.com/grails/grails-core/blob/7.0.x/grails-logging/src/main/groovy/org/grails/compiler/logging/LoggingTransformer.java
- Don't add logging behavior to classes that extend
GrailsAutoConfiguration
- https://github.com/grails/grails-core/issues/10969 - can't call
from a static context
- no IDE support in IntellIj
- We will continue discussing this on the mailing list and revisit.
- We discussed the need for an Open Source Grails plugin for IntelliJ
- We could start by adding a gdsl to our projects to allow for
autocompletion in the community edition
- We discussed how to communicate package renames and artifact moves
- As part of going to the ASF, we have to change our artifact names.
- As part of the artifact rename, we intend to repackage a
significant amount of projects so that no project's package name will
overlap with third party components. This is a security feature.
- We want to make it easier for developers to find where a class
moved. Google searches were initially suggested, but
maintaining an index
would be ideal.
- We would love ideas on how to make this simpler in the future.
- We are still evaluating OpenRewrite, but so far it doesn't look
like it will work for complex groovy projects.
-James
