Okay, I wrote about that because it was related to the i18n thing you were mentioning but yes, we are not in a rush for that in Grails 7 👍🏻
Gianluca Sartori -- https://dueuno.com On Mon, 11 Aug 2025 at 16:15, James Daugherty <jdaughe...@jdresources.net.invalid> wrote: > Hi Gianluca, > > We have discussed moving to a starter approach for this reason, but > the original plan was to tackle that in Grails 8 instead of 7. > > I was hoping we could take a more targeted approach in 7 given that we > will likely only do 1 more RC. > > -James > > On Mon, Aug 11, 2025 at 8:40 AM Gianluca Sartori <g.sart...@gmail.com> > wrote: > > > > I’ve always asked myself why Grails has so many dependencies that are > > required by the framework and exposed to the end user. > > > > Not only i18n but also: > > - grails-web-boot > > - grails-url-mappings > > - grails-services > > - grails-interceptors > > > > I see them, from an architectural point of view, as core components. App > > developers should not see them as decoupled, they should logically be > > encapsulated by grails-core. > > > > Can we hide them somehow? In the end we need them for any Grails app. > > > > Or we do have use cases where a Grails app does not require them? > > > > Gianluca Sartori > > -- > > https://dueuno.com > > > > > > On Sun, 10 Aug 2025 at 16:37, James Daugherty > > <jdaughe...@jdresources.net.invalid> wrote: > > > > > Hi Everyone, > > > > > > While working on the Micronaut change, I discovered that i18n > > > configuration is basically required for both the Domain & Controller > > > projects, but loosely being enforced: > > > > > > 1. `grails-controllers` has a runtimeOnly dependency in its > build.gradle > > > on i18n > > > 2. DomainClassGrailsPlugin from `grails-domain-class` has a dependsOn > of > > > i18n > > > 3. ControllersGrailsPlugin from `grails-controllers` has a dependsOn of > > > i18n > > > > > > The i18n project only has 2 purposes: 1. to define the location of the > > > message properties 2. to support reloading them. Given that the > > > grails-i18n project has limited scope & dependencies, I'd like to > > > propose the following: > > > > > > 1. We make grails-i18n an API dependency of grails-domain-class. > > > - By doing so grails-controllers & grails-domain-class both will > > > always have the i18n plugin applied. > > > 2. We consider the i18n plugin package private and change its group > > > coordinate to `org.apache.grails.i18n`. This means we will no longer > > > require end user apps to include it & it will be included via our > > > other 'org.apache.grails' dependencies. > > > > > > I'm proposing this because both controllers & domains technically > > > require i18n to be defined, but we're only having it defined as a side > > > effect of users including it in their dependencies. Having end users > > > define it is exposing an implementation detail of Grails, which goes > > > against our goal of simplicity / convention over configuration. > > > > > > As to why this is so important: We have gradually moved towards using > > > AutoConfiguration in Grails 7. Our end goal is to have all of the > > > grails-core configuration defined via AutoConfiguration or > > > Configuration classes. Scott has done a lot of the initial work, but > > > there's more work that may have to be done to get scaffolding working > > > with the micronaut loading approach. Having transitive dependencies > > > like this prevents us from adding these dependencies as we move to > > > AutoConfiguration. > > > > > > -James > > > >
