We could do starters for end apps if we want, now that we need another RC. (If anyone has time to change the Forge and the Profiles) If we don't have time we can always add `org.apache.grails.i18n:grails-i18n` as a runtimeOnly dependency on any library that is mandatory like `grails-core` and then move it to a base starter later.
What about `grails-dependencies-starter-rest` to separate it from full web dependencies? Den mån 11 aug. 2025 kl 14:03 skrev James Daugherty <jdaughe...@jdresources.net.invalid>: > 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 > > > > > > > > > > > > > > >
