jdaugherty commented on PR #39: URL: https://github.com/apache/grails-gradle-publish/pull/39#issuecomment-5870827975
@matrei thanks for the rerun with `projectVersion` in `gradle.properties`, that's the path that matters. Your points are addressed in e28948e (pushed): 1. **Help text:** the leftover sentence after "...not available with Isolated Projects." is gone; the message now matches the README. 2. **`findProjectProperty`:** `@PackageScope` again (the unit test is in the same package), so it stays out of the API grails-core extends. 3. **Module indentation:** rewritten `.module` files are now written with Gradle's two spaces per level and a trailing newline. I checked a rewritten file against an untouched one from the same build: same indent steps and empty-array rendering, and it still parses, so a rewritten file only differs where a version was added. 4. **Configuration cache in `doLast`:** left as you suggested. The proper fix is to build the version map from the configurations' `ResolutionResult` providers at configuration time instead of touching `project` in the task action; I'd rather do that together with the rest of the configuration-cache work for publishing. On the module metadata differences, I ran `publishAllToMavenLocal` on the current grails-core (grails-gradle, grails-core, grails-forge, JDK 21) with `1.0.0-RC1` resolved the normal way and then with this branch, and diffed every published pom and `.module` (337 files each): - **Poms:** the only differences are the plugin's own version string (the BOMs' `grails-publish-plugin.version` property and `grails-gradle-plugins`' dependency). No other pom line changed, as expected: the poms already carry every version inline. - **Module metadata:** the same 11 modules you saw gain a version, for 15 dependencies in total. 14 of them are in variants with no platform dependency at all, so consumers had nothing to resolve the version from unless they imported `grails-bom` themselves: `compileOnlyApi` declarations such as `jakarta.servlet-api` in grails-controllers, -converters, -mimetypes, -web-core, -web-gsp and -web-taglib and `jakarta.mail-api` in grails-mail (the BOM is only on `implementation`, so it never reaches `apiElements`), and `testFixturesApi` dependencies in grails-core, grails-web-common and grails-geb. The 15th is `hibernate-envers` in the test fixtures of grails-data-hibernate7-dbmigration-core, whose variant does carry `grails-hibernate7-bom`; RC1 published `hibernate-core` there with `requires 7.4.10.Final` next to a versionless envers (it's only declared as `testFixturesApi`, so version mapping from `runtimeClasspath` missed it), so the module now states both at the same version. Overri des through `bom-property-overrides` still win, since it applies `strictly()`. - Everything else differs only in jar sizes and checksums (my runs had no `SOURCE_DATE_EPOCH`). -- 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]
