I understand the concern. I'm simply reluctant to bring in more than absolutely necessary to grails-core. grails-mail is actually very disconnected with Grails (only has compileOnly dependency configuration), registers beans with an Spring Boot Auto Configuration and is only needed in runtimeOnly configuration for ui-examples-simple and ui-examples-extended test apps. I might certainly be missing something but I don't see how this could be a problem.
Den lör 30 maj 2026 kl 16:11 skrev James Daugherty via dev <[email protected]>: > > The point of this vote was to prevent having to comment out spring > security when we do major upgrades & consolidate to one repository. > If we're going to kick that can down the road, I'm not sure we should > merge it (my vote was contingent on this). > > To my knowledge, it's only spring security that's included in core. > Also, because it's included in our project, our solution for major > changes had to be: comment the project include out. The purpose of > merging to a single repository is so we can change it all at once and > not leave tests in a broken, unrunnable state. This is the #1 lesson > learned I had from our original Grails 7 development & from our ASF > merge. A mono repo only works if you can work on the code together > with incremental changes and testing. Otherwise, let's say we make a > major plugin change (which we have explicitly talked about doing), we > suddenly can't run the tests because Grails Mail uses the older plugin > contract. We could alternatively abandon Grails Mails in our tests > and I'd be happy with that solution. What I don't want is to include > a project that depends on Grails that then prevents us from changing > Grails unless we disable the include. This often results in the test > staying disabled for a long time, and when we re-enable it, something > is broken that we didn't expect. This has been a source of huge time > syncs in the past. > > On Fri, May 29, 2026 at 4:46 AM Mattias Reichel <[email protected]> wrote: > > > > But we already have some dependencies that are only used in test apps, > > could not grails-mail be added to this list? > > > > In gradle.properties: > > > > # Libraries only specific to test apps, these should not be exposed > > ersatzVersion=4.0.1 > > grailsSpringSecurityVersion=8.0.0-SNAPSHOT > > jbossTransactionApiVersion=2.0.0.Final > > > > Den fre 29 maj 2026 kl 00:45 skrev James Daugherty via dev > > <[email protected]>: > > > > > > Because of how the gradle dependency resolution works, it would very > > > likely > > > break or cause core to depend on an external change. This is why I viewed > > > it as a must. If the tests removed the plugin, it could be removed. > > > > > > On Thu, May 21, 2026 at 2:57 AM Mattias Reichel <[email protected]> wrote: > > > > > > > I think grails-mail is only used in functional tests, so I'm not sure > > > > that grails-mail needs to be merged into grails-core. > > > > > > > > Den ons 20 maj 2026 kl 20:25 skrev James Fredley > > > > <[email protected] > > > > >: > > > > > > > > > > Before we create a vote thread to consolidate grails-spring-security > > > > into grails-core, grails-spring-security depends on > > > > org.apache.grails:grails-redis and org.grails.plugins:grails-mail and > > > > given > > > > the policies we apply to grails-core, I think both of those would have > > > > to > > > > be merged into grails-core, also. > > > > > > > > > > Agree or disagree? > > > > > > > > > > James > > > > > > > > > > On 2026/05/18 12:04:43 James Daugherty wrote: > > > > > > We briefly discussed this on the weekly, but I thought this deserves > > > > its > > > > > > own thread: I would like to propose we merge grails-spring-security > > > > into > > > > > > grails-core and its associated dependencies (means grails-redis). > > > > > > > > > > > > The reason we did not merge these before was the security build > > > > > > often > > > > hung > > > > > > and took 2+ hours. Recently Mattias has worked to make that more > > > > stable. > > > > > > It’s now running in 1-2min. > > > > > > > > > > > > We also have not done the best job releasing dependency updates on > > > > > > this > > > > > > repo and by moving it into core we can ensure timely updates. We can > > > > > > also easily identify dependencies that should really be in the bom. > > > > > > > > > > > > I would propose we move the 7.0 branch into 7.0.x so we can cease > > > > > > all > > > > > > activity on spring security. > > > > > > > > > > > > What do others think? > > > > > > > > > > > > -James > > > > > > > > > >
