borinquenkid commented on code in PR #15972:
URL: https://github.com/apache/grails-core/pull/15972#discussion_r3567316875
##########
grails-data-neo4j/boot-plugin/build.gradle:
##########
@@ -17,27 +17,77 @@
* under the License.
*/
+plugins {
+ id 'groovy'
+ id 'java-library'
+ id 'org.apache.grails.buildsrc.properties'
+ id 'org.apache.grails.buildsrc.compile'
+ id 'org.apache.grails.buildsrc.publish'
+ id 'org.apache.grails.buildsrc.sbom'
+ id 'org.apache.grails.gradle.grails-code-style'
+}
+
+version = projectVersion
+group = 'org.apache.grails'
+
+ext {
+ gormApiDocs = true
+}
+
dependencies {
- compileOnly "org.springframework.boot:spring-boot-cli:$springBootVersion",
{
- exclude group:'org.codehaus.groovy', module:'groovy'
- exclude group:'jline', module:'jline'
- }
- api "org.springframework.boot:spring-boot-autoconfigure:$springBootVersion"
+ implementation platform(project(':grails-bom'))
- api "org.codehaus.groovy:groovy"
- api project(":grails-datastore-gorm-neo4j")
- api "org.springframework:spring-tx:$springVersion"
+ api 'org.springframework.boot:spring-boot-autoconfigure'
+ // DispatcherServletAutoConfiguration (referenced via
@AutoConfigureBefore) moved to spring-boot-webmvc.
+ api 'org.springframework.boot:spring-boot-webmvc'
+ api 'org.apache.groovy:groovy'
+ api project(':grails-datastore-gorm-neo4j')
+ api 'org.springframework:spring-tx'
testRuntimeOnly "org.neo4j.test:neo4j-harness:$neo4jVersion"
- testImplementation ("org.spockframework:spock-core:$spockVersion") {
- exclude group: 'junit', module: 'junit-dep'
- exclude group: 'org.codehaus.groovy', module: 'groovy-all'
- exclude group: 'org.hamcrest', module: 'hamcrest-core'
- transitive = false
+ testImplementation 'org.spockframework:spock-core'
+ testRuntimeOnly 'org.junit.platform:junit-platform-launcher'
+}
+
+test {
+ useJUnitPlatform()
+
+ // The embedded Neo4j 3.5.x test harness reflectively pokes JDK internals
(Throwable's
+ // message field, sun.nio.ch.FileChannelImpl's lock accessors) at startup;
JDK 9+ strong
+ // encapsulation blocks that without these opens.
+ jvmArgs = [
+ '--add-opens', 'java.base/java.lang=ALL-UNNAMED',
+ '--add-opens', 'java.base/sun.nio.ch=ALL-UNNAMED',
+ ]
+}
+
+// The Spring Boot BOM (pulled in transitively via grails-bom) force-upgrades
Jetty to a 12.x
+// platform version. The embedded Neo4j 3.5.x test harness (neo4j-harness,
test-only) is compiled
Review Comment:
Fixed properly: `neo4j-java-driver` is now pinned in a dedicated
`grails-neo4j-bom` module rather than inside `grails-bom` itself, so the
`strictly 4.4.13` constraint only applies to apps that actually pull in
`grails-data-neo4j` — everyone else inherits Spring Boot's managed driver
version (currently 6.1.0) unchanged. This mirrors the existing
`grails-hibernate5-bom`/`grails-hibernate7-bom` pattern already used for the
same kind of datastore-specific version override. Worked this through under
direct supervision, not autonomously.
Concretely:
- `dependencies.gradle`: carved `neo4j-driver.version`/`neo4j-driver` out of
the shared `grails-bom`/`grails-hibernate5-bom` block into its own
`grails-neo4j-bom` branch.
- New `grails-neo4j-bom` module (`grails-bom/neo4j/build.gradle`), layered
on top of the default `grails-bom` — matches the Hibernate5/7-BOM structure
exactly, including `enforcedPlatform()` support and `extractConstraints`/doc
generation wiring.
- `grails-data-neo4j-core`/`grails-plugin`/`boot-plugin` and all 5 example
apps now consume `grails-neo4j-bom` instead of `grails-bom`.
- Wired into `settings.gradle`, `publish-root-config.gradle`, the
`validateDependencyVersions` validator's known-BOM set, and
`GrailsGradlePlugin`'s BOM auto-detection.
- Bonus: this also retires a workaround — `grails-data-mongodb-docs`'s
`validateDependencyVersions` no longer needs to tolerate a `neo4j-driver` floor
it has nothing to do with, since that coordinate isn't declared in `grails-bom`
anymore at all.
- Wired `validateDependencyVersions` onto all three neo4j modules for the
first time (previously not applied on any of them). That surfaced a real,
separate pre-existing gap: the embedded-Neo4j-3.5.x test harness's Jetty
downgrade was never declared as an `allowedBomOverrides` exemption. Now
declared once in the shared `neo4j-harness-test-config.gradle` so it covers all
three modules.
**Gap flagged, not fully closed:** wiring the validator onto
`grails-data-neo4j`'s `grails-plugin` module exposed a genuine evaluation-order
race in `GrailsGradlePlugin.applyGrailsBom`/`declaredGrailsBoms`. It
auto-injects the default `grails-bom` as an external Maven coordinate onto
every configuration lacking a hand-declared BOM, checking "already has a BOM?"
inside `afterEvaluate` — at which point `:grails-neo4j-bom`'s own `group`
assignment isn't guaranteed to have run yet, since Gradle doesn't order sibling
project evaluation. Every existing module masks this because they all use the
default `grails-bom` (same name either way, and continuously snapshot-published
so external resolution just works). `grails-neo4j-bom` is the first non-default
BOM a `grails-plugin`-convention module has used, so it's the first to hit it:
a bogus "declares more than one Grails BOM" error, then an
unresolvable-external-coordinate failure once worked around. Worked around
locally with `grails { b
om = null }` on this one module (the plugin's own documented escape hatch)
rather than touching the shared plugin class. The race itself is still latent
and will resurface for the next module introducing a new, unpublished BOM name
this way — worth a follow-up issue.
Verified: `grails-neo4j-bom`'s extracted constraints show `neo4j-java-driver
| 4.4.13 | grails-neo4j-bom` while the default `grails-bom`'s constraints show
`6.1.0` (Spring Boot-managed) with no override. Dependency resolution on all
three neo4j modules confirms `neo4j-java-driver:6.1.0 -> {strictly 4.4.13}`.
All three modules' `validateDependencyVersions` now passes clean. Full
`grails-data-neo4j-core` test suite matches baseline (same single pre-existing
`OptimisticLockingSpec` flake, no regressions).
--
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]
