Sounds good. What about end user apps - we had not pushed the starter approach to them yet. Are you suggesting we do? What apps that are just rest apps? The web starter contains gsp, but those apps would not use it.
On Mon, Aug 11, 2025 at 7:34 AM Mattias Reichel <mattias.reic...@gmail.com> wrote: > I think libraries that need `grails-i18n` on the compileClasspath should > explicitly declare it themselves. > > Den mån 11 aug. 2025 kl 13:12 skrev James Daugherty > <jdaughe...@jdresources.net.invalid>: > > > 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 > > > > > > > > > >
