jamesfredley opened a new pull request, #15611: URL: https://github.com/apache/grails-core/pull/15611
## Summary Fixes profile resolution failure in the Grails CLI when `GRAILS_REPO_URL` points at an Apache staging repository (or any repository whose published BOM does not declare `org.apache.grails.profiles:*` coordinates). This was hit by the **7.0.11 release manager** during the staging vote, with the release wrapper failing as: ``` Updated wrapper to version: 7.0.11 Grails repo url override detected, including repo: https://repository.apache.org/content/groups/staging Resolving dependencies... | Error Error occurred running Grails CLI: Could not find artifact org.apache.grails.profiles:web:jar: in grails-override-repo (https://repository.apache.org/content/groups/staging) ``` Note the **empty version** after `web:jar:`. ## Root cause Two defects combine to produce the empty-version request: 1. `AbstractJarProfileRepository.getProfileArtifact` defaults the profile version to `null` and only fills it from user-supplied `grails.profiles` settings, which are absent in a clean release-manager test environment. The downstream `MavenResolverGrapeEngine.createArtifact` (line 170) then attempts to recover a BOM-managed version, but that fallback also returns `null` because of (2). 2. The published `grails-bom` / `grails-base-bom` `<dependencyManagement>` does not list any `org.apache.grails.profiles:*` coordinates. Profile subprojects apply `org.apache.grails.gradle.grails-profile`, which is not in the `publishedProject` filter in `grails-bom/base/build.gradle`. ## Fix * **Default the profile artifact version to `Environment.grailsVersion`** in `AbstractJarProfileRepository`. Profiles are released in lock-step with grails-core since the monorepo move, so the CLI version is the correct profile version. User-supplied `grails.profiles` settings still override per profile. * **Include the `grails-profile` plugin in the BOM's `publishedProject` filter** so the published `grails-bom` and `grails-base-bom` POMs declare profile coordinates in `<dependencyManagement>`. The default / hibernate5 / micronaut BOMs inherit constraints via `api platform(project(':grails-base-bom'))`, so a single edit propagates. * **Add `AbstractJarProfileRepositorySpec`** with regression coverage for the version-default and explicit-GAV paths so this cannot recur silently. ## Verification * `./gradlew :grails-shell-cli:compileGroovy :grails-shell-cli:compileTestGroovy` BUILD SUCCESSFUL * `./gradlew :grails-shell-cli:test --tests "org.grails.cli.profile.repository.AbstractJarProfileRepositorySpec"` -> both specs **PASSED** * `./gradlew :grails-base-bom:generatePomFileForMavenPublication` -> generated `pom-default.xml` `<dependencyManagement>` now declares all 7 profile coordinates: `org.apache.grails.profiles:{base,plugin,profile,rest-api,rest-api-plugin,web,web-plugin}`. * Independent control: a separate Gradle-based 7.0.11 staging consumer build (`curl https://latest.grails.org/create/WEB/myapp`, `grailsVersion=7.0.11`, staging repo added to `build.gradle`) resolves all `org.apache.grails:*` artifacts at 7.0.11 and `./gradlew assemble` succeeds. Only the CLI/wrapper code path was affected by the bug fixed here, which matches expectations. ## Release note (suggested) > Fixes a regression in the Grails CLI where `grails create-app` fails to resolve the `web` profile when `GRAILS_REPO_URL` points at a repository whose BOM does not declare `org.apache.grails.profiles:*` coordinates (e.g. an Apache staging repository before promotion). The CLI now falls back to the running Grails version for profile resolution, and the published BOM now declares profile coordinates so the existing dependency-management fallback also works. ## Notes for the release process 7.0.11 staging should be **dropped** and the release re-cut once this is merged - the CLI/wrapper path is unusable as-is for anyone testing 7.0.11 against the staged artifacts. Assisted-by: claude-code:claude-opus-4 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
