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
* Discussed how multi-project builds do not work correctly with the reloading changes - ticket for problem https://github.com/apache/grails-core/issues/14977#issue-3327665128 - ticket for documentation https://github.com/apache/grails-core/issues/14975 - need to fix the 'exploded' logic in GrailsGradlePlugin so that multi-project builds do not use jar files * Discussed the continuing need to have a way to start & stop any Grails Application from any generated source - several use cases exist for this feature: -- plugins that need to have an environment like bootRun / bootJar / bootWar (for example the db migration plugin - dbm-update functions differently than boot* tasks) -- verification process of a release could make use of this to automate testing -- testing real end-to-end scenarios in the code - solution 1: proposal to add a flag to terminate running grails app once started -- security considerations: only use flag if configuration allows - solution 2: add a health check and then use mbean to stop the app (see base profile script) - initial reaction is to prefer solution #2. we can take an iterative approach here, doesn't have to be done for 7.0, but would be nice for 7.1 to reduce release verification time. * Renewed a discussion around having a grails plugin bom - ticket: https://github.com/apache/grails-plugins-metadata/issues/127 - would be useful for grails-forge since some versions outside of core are maintained in a pom.xml that's checked in. Also would allow other externa plugins to be added to forge. - need a way to know the maximum version of Grails supported by a given plugin - grails-core does not depend on plugins, but we have app generators inside of core. We do not want to have to release core for every plugin release. - how do we handle the ASF release requirements too? The bom is just an index of known software, and not code. -- proposed solution: use lazy votes & document decisions. This aligns with other ASF projects like training, common's (the parent pom), etc. We would use lazy votes to periodically release, and then as part of any release, those could be accepted like other projects do. * Our friends of Grails gave an update on seeing significant more activity since posting on social media last week. * grails-forge migration - currently hosted at GCP - need to find where to host -- ASF has VMs, but problematic for patching / maintenance. -- initial discussions with ASF infra revealed they do have an AWS account, but do not have experience with container hosting. - We decided to hold off on forge moving until after Grails 7 release. - We know the existing environment wasn't set up with any type of IaC, so a migration would likely be manual. * significant recent grails-geb configurations - 2 open PRs related to: 1. fixing the recording when multiple tests exist in file 2. fixing GebConfig for dynamic configuration - Discussed contributing upstream as a separate library or being directly involved in geb project. - we are also amenable to making the grails-geb project less dependent on grails or splitting it so that we maintain the stand alone support. - Care in discussion with Geb mailing list to see what's feasible * coordinates have changed to Grails Data - discussed dropping the 'GORM' reference - no consensus, but we have decided to start a mailing list thread to discuss further there * groovydoc discussion & whether we want to continue to maintain separate groovydoc for each grails-data project - https://github.com/apache/grails-core/issues/14997 - We have decided to remove the grails-data aggregated groovy doc and only have 1 aggregated. * forge-documentation is no longer being published - we decided to remove the forge documentation that's checked in since the grails docs have been enhanced to the point that it's redundant. - question: the groovydocs aren't being published as before -- answer: because we publish the individual groovydoc jar, it can still be consumed. Since it's only for app generation, and not the grails-core project itself, we decided to not publish that documentation separately like grails-core does * grails-gradle groovydoc not publishing - we have to continue to publish this since some common libraries were pulled up into grails-gradle - we want to include the API docs from grails-gradle in the aggregated groovydoc for grails-core - https://github.com/apache/grails-core/issues/14978 * grails-microanut status update - grailsApplication wiring blocks switching to `@Configuration` - grailsApplication dependency seems dependent on config auto-wiring - we should consider standardizing our configuration as a bean going forward, and thus giving us a path forward to move to Configuration classes - for the micronaut changes, the idea is to rework the bean names so that the inner bean is only wired if one isn't defined by using a post registry processor in grails-gsp * we reviewed all relevant issues on the 7.0.0-RC2 milestone & updated the associated tickets - https://github.com/orgs/apache/projects/487/ * A concern was raised about the verbose logging. - previously it has been mentioned that groovy has a way to filter long stack traces. We should investigate how to address this in later 7.x versions. * We brought people's attention to the performance concerns over invokeDynamic & recent groovy mailing list thread here: https://lists.apache.org/thread/n9c055nw1mwtnvmlgqsk5jlfov6vgrky - for groovy4, invokedynamic can still be disabled: https://docs.gradle.org/current/javadoc/org/gradle/api/tasks/compile/GroovyCompileOptions.html - follow groovy 5 thread for progress -James
