codeconsole commented on PR #16170:
URL: https://github.com/apache/grails-core/pull/16170#issuecomment-5336663122
Rebuilt on a different mechanism after CI failed. The original approach was
not fixable.
### Why it failed
Publishing the `noindy` jar as a secondary variant of
`apiElements`/`runtimeElements` made every module ambiguous to a configuration
that requests **no attributes at all**:
```
Could not resolve all dependencies for configuration
':grails-data-hibernate5-core:tck'.
> More than one variant of project ':grails-datamapping-tck' matches the
consumer attributes:
- Configuration ':grails-datamapping-tck:runtimeElements':
- Configuration ':grails-datamapping-tck:runtimeElements' variant
noindy:
```
Every unmatched line reads *"but the consumer didn't ask for it"*, including
`org.gradle.usage`. The `tck` and CLI companion probe configurations declare
nothing, so every variant is an equally good candidate.
No attribute rule repairs this. A disambiguation rule receives only the
values candidates declare, so the variant *without* the attribute never appears
among them — instrumenting the rule prints `RULE_INVOKED consumer=null
candidates=[false]`, leaving no value meaning "the default one". Declaring the
attribute on both variants makes the rule work but breaks every plain consumer
of a Grails artifact, which is the problem that led to the asymmetry in the
first place.
Worth noting the one existing precedent here, `GrailsExplodedPlugin`,
creates its secondary variant only `if (grails.developmentRun)` — it exists
during `bootRun` and never during normal resolution, sidestepping the general
case rather than solving it.
### What replaces it
The `noindy` jar is now a plain Maven classifier that adds **nothing** to
the published metadata — the module keeps exactly the variants it always had,
so no consumer's resolution changes and the ambiguity is unreachable rather
than fixed.
Selection is assembled on the consuming side. An application setting `indy =
false` registers a `ComponentMetadataRule` that derives a variant from the
classifier for the modules it names:
```groovy
grails {
indy = false
noindyModules = ['org.apache.grails:grails-core',
'com.example:my-plugin']
}
```
That variant exists only inside the opted-in build, whose schema also
carries the disambiguation rule needed to choose between it and the main
artifact.
Verified across five scenarios, including the two that broke CI: an artifact
view constraining nothing, and an ad-hoc configuration with no attributes. Both
now resolve a single artifact. A dependency publishing only the main artifact
still resolves under either setting.
### Two limitations, both inherent
- **The module list is required.** Applying the rule unguarded fails hard —
it tries to fetch `groovy-5.0.8-noindy.jar`. Platforms fail the same way, and
the Grails BOM is a platform every app depends on, so there is no safe
group-wide default. Modules advertise their classifier through a
`Grails-Noindy-Artifact` manifest attribute (mirroring `Grails-Cli-Artifact`)
so the list can later be discovered by a probe rather than written by hand;
that discovery is not implemented.
- **Component metadata rules do not apply to project dependencies**, so a
composite or multi-project build always resolves the main artifact. Documented
in the guide.
### Standing recommendation unchanged
This makes the approach viable, not necessarily right. `noindy` artifacts
still cannot appear in a native image, which was the motivation, and #16171
delivers the same native guarantee in 73 lines with no module list to maintain
and green CI. I would still merge #16171 — but the choice is now a real
trade-off rather than one option being unworkable.
--
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]
