To go back to security fully, I think we'll need to make a script that
downloads the jars, builds locally, and then compares. Currently the
script locally just builds twice and compares.
As a starter, I'll ask security if they're ok with diffing via the
decompile approach we've been taking.
On M
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.go
I think we should proceed with updating the ASF security team on the progress
so we receive updated feedback.
Since we are working on 7.0.0-SNAPSHOT, will most likely need Groovy 4.0.27 for
Grails 7.0.0-M4 and already put the Apache Snapshot Repository in the right
locations to pull Grails SNAP
FYI: I reached out to Jetbrains support: if you have the grails plugin
enabled in IntelliJ and try to use grails-core it will cause the source
files to not be browseable.
https://youtrack.jetbrains.com/issue/IDEA-366647 is the upstream ticket.
I've updated our internal tracking ticket as well:
http
Paul was able to fix the groovydoc differences via groovy 4.0.27-SNAPSHOT.
I've updated the ticket; we're down to these jars differing:
grails-cache/build/libs/grails-cache-7.0.0-SNAPSHOT.jar
grails-datamapping-tck/build/libs/grails-datamapping-tck-7.0.0-SNAPSHOT.jar
grail
The largest benefit: if repo.grails.org gets removed tomorrow, we know what
will break and why. Today, that repo points to so many things that I don't
think we have a good understanding of what's required for various grails
applications.
The second benefit: I know of several old libraries that ar
