jdaugherty commented on PR #15948:
URL: https://github.com/apache/grails-core/pull/15948#issuecomment-4930362965
The published Gradle Module Metadata still contains capability-style
dependencies (org.apache.grails:grails-core +
requireCapability('org.apache.grails:grails-core-cli')) — violating the split's
design rule that external consumers must see the plain -cli coordinate, never
capabilities. When Gradle resolves that from a Maven repo, it selects
grails-core's cliRuntimeElements variant, follows its available-at redirect to
the standalone grails-core-cli module, and then sees both nodes providing the
same capability — a self-conflict. I reproduced it with a one-dependency
project against build/local-maven, and it fails with both timestamped and
non-unique snapshots, so it's not a snapshot-timestamp issue.
There are two distinct leak paths:
1. Every -cli companion (grails-scaffolding-cli, grails-data-hibernate5-cli,
grails-web-url-mappings-cli, dbmigration, spring-security plugins):
configureDependencyMapping (publishResolvedCoordinates in
GrailsCliArtifactGradlePlugin) rewrites the POM correctly to grails-core-cli,
but the GMM still records grails-core + requestedCapabilities — and Gradle
consumers prefer the GMM.
2. grails-console declares the capability dep in its main api
(grails-console/build.gradle:43). Its main java component has no dependency
mapping at all, so its GMM leaks the capability dep — and worse, its POM
collapses it to plain grails-core, meaning Maven consumers silently lose the
cli dependency entirely.
I'm still researching possible solutions for this one.
--
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]
