We can alternatively remove Grails mail as a dependency. Either would work in my mind. But it does have a dependency on Grails-core - the plugin api itself. I was going to start on this work and we did vote on bringing mail over, but if you're objecting now I can delay / revisit this.
On 2026/05/31 12:25:45 Mattias Reichel wrote: > 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 > > > > > > > > > > > > >
