The grails-i18n message source can be used in at least domains, controllers, services, gsps and taglibs. Moving it from an explicitly declared dependency in end Grails apps to a default, transitively provided dependency follows the DRY and convention-over-configuration principals of Grails. org.apache.grails.i18n:grails-i18n follows the approach taken during renaming and since it appears we will need to do a 7.0.0-RC2, I think this change can be made for 7.
James Fredley On 2025/08/10 14:36:23 James Daugherty 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 >
