jamesfredley commented on PR #16073: URL: https://github.com/apache/grails-core/pull/16073#issuecomment-5138533656
## Correction: the "narrow window" I described above does not exist In my previous comment I suggested the fix was to find a generation point late enough for `withDependencies` discovery but still early enough for Spring DM. I tested that and it is **not** achievable with this design. Recording the result so nobody repeats it. I moved pom generation into `gradle.projectsEvaluated`, which runs after every project is evaluated and still before the task graph is computed - on paper, exactly the window required. | Generation point | Generated BOM | Cold build | |---|---|---| | Root project configuration (current branch) | 102 deps, **0** of 9 `grails-*-cli` | passes | | `gradle.projectsEvaluated` | **111 deps, all 9 `grails-*-cli`** - matches published exactly | **fails**, ~40 coordinates unresolved | So the BOM is only complete once all projects have been evaluated, but by that point Gradle has already attempted and cached the failed lookup for `org.apache.grails:grails-bom`, and the later-written pom is never reconsulted. Writing the pom before any resolution attempt and having a complete BOM are mutually exclusive within a single invocation. This is the same missing-module caching behaviour that made the very first version of this fix fail: the pom existed on disk at the end of the run, but resolution had already given up. It is not a VFS issue - `--no-watch-fs` makes no difference. ### What that means for this PR The approach of "generate the BOM poms during the build and serve them from a local repository" cannot be made correct as written. Any fix needs to break the circularity rather than reposition it. Options worth weighing: 1. **Produce the poms outside the consuming invocation** - a separate bootstrap step or a dedicated task run before the main build, so the poms are present from the very start and completeness is unconstrained by ordering. 2. **Remove the repository requirement entirely** - stop importing a BOM artifact and drive the example's managed versions from `dependencies.gradle` directly, which is already the single source of truth and is already read by this example for its `logback.version` override. That loses the "imports a real Maven BOM" fidelity but keeps what the example is actually for: a migrated Grails 7 application where Spring DM, not the platform, manages versions. 3. **Leave the example excluded on unpublished versions** via the `-PbomSnapshotNotPublished` guard this PR removes, and accept that it validates the last-published BOM rather than the commit. Option 2 is the one I would pursue: it makes the example correct (it would finally test the commit's versions) and version-proof, at the cost of coverage nobody appears to rely on, since Grails 8 applications use the platform BOM. The findings in this PR stand on their own regardless of which route is taken - in particular the `BomPropertyOverridesPlugin` coordinate bug (`grails.core.ROOT:grails-hibernate5-bom:unspecified`) is a genuine defect independent of the example, and could be split into its own PR. -- 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]
