If we set it as a runtime dependency, then we can’t compile if switching to AutoConfiguration - we won’t be able to reference the Config class from controllers or domain plugins.
On Mon, Aug 11, 2025 at 6:08 AM Mattias Reichel <mattias.reic...@gmail.com> wrote: > I think we can rename `grails-i18n` to "internal" > ´org.apache.grails.i18n:grails-i18n` and think of it as a "Grails Platform" > library that is always available as part of a Grails application. > I don't think we need to make it an api dependency, but rather runtimeOnly > as it is completely self-contained without a public API and is only needed > at runtime. > > Where we put it is a good question. > Perhaps in a `grails-dependencies-starter-base` that other starters like > `grails-dependencies-starter-web` can include? > > /Mattias > > Den sön 10 aug. 2025 kl 16:37 skrev James Daugherty > <jdaughe...@jdresources.net.invalid>: > > > 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 > > >
