jamesfredley commented on issue #16125:
URL: https://github.com/apache/grails-core/issues/16125#issuecomment-5243550708
### I prototyped the coordinate shim - it works, but only up to a point
Rather than leave option 3 as speculation, I implemented it as Gradle
dependency substitution in a stock 8.0.0-M5 app and measured the result on the
two community-requested plugins from #15044. The outcome is split, which I
think sharpens the recommendation.
The rule set applied to a plain generated app:
```groovy
// map pre-Apache org.grails coordinates onto their org.apache.grails
equivalents
ext.legacyGrailsCoordinateMap = [
'org.grails:grails-core' :
"org.apache.grails:grails-core:$grailsVersion",
'org.grails:grails-web-boot' :
"org.apache.grails:grails-web-boot:$grailsVersion",
'org.grails:grails-plugin-domain-class' :
"org.apache.grails:grails-domain-class:$grailsVersion",
'org.grails:grails-plugin-mimetypes' :
"org.apache.grails:grails-mimetypes:$grailsVersion",
'org.grails:grails-web-common' :
"org.apache.grails.web:grails-web-common:$grailsVersion",
'org.grails:grails-web-url-mappings' :
"org.apache.grails.web:grails-web-url-mappings:$grailsVersion",
'org.grails:grails-dependencies' :
"org.apache.grails:grails-dependencies-starter-web:$grailsVersion",
]
configurations.configureEach {
resolutionStrategy.dependencySubstitution {
legacyGrailsCoordinateMap.each { String legacy, String replacement ->
substitute module(legacy) using module(replacement) because
'grails-core#16125 legacy org.grails coordinate shim'
}
}
}
```
### Result 1: `com.bertramlabs.plugins:seed-me:7.0.0` - fully works
Previously it could not even resolve. With the shim it compiles, packages,
**boots, and registers its beans**:
```
Loaded 24 Grails plugins in load order: [seedMe (7.0.0-M1), restResponder
(8.0.0-M5), geb (8.0.0-M5),
dataBinding (8.0.0-M5), sitemesh3 (8.0.0-M5), i18n (8.0.0-M5), core
(8.0.0-M5), ... cache (8.0.0-M5)]
SEED_BEANS=[seedService, seedme.AdminSeedController]
```
```
SeedShimSpec > the legacy plugin loads and registers its beans under the
coordinate shim PASSED
```
A Grails 7-M1-era plugin running unmodified beside Grails 8.0.0-M5. So the
approach is viable, not just theoretical.
### Result 2: `com.bertramlabs.plugins:grails-force-ssl:7.0.0` - resolves,
then fails at runtime
The shim gets it past resolution and compilation, but the context fails to
start:
```
Error creating bean with name 'forceSSLInterceptor': Failed properties:
Property 'grailsRenderViewMutator' threw exception:
java.lang.AbstractMethodError
```
That is a real binary incompatibility in the interceptor API, not a
coordinate problem. No amount of coordinate mapping fixes it - the jar has to
be recompiled against Grails 8.
### What this means for the issue
The split is the useful part:
- Coordinate substitution **is** a genuine migration aid. It rescued one of
the two plugins outright, and it converts an unresolvable build into either a
working app or a specific, diagnosable runtime error.
- It is **not** a general fix, and it should not be presented as one. It
moves the failure from "cannot resolve, empty version, no explanation" to "here
is exactly which class and method is binary-incompatible", which is a much
better place for a user or a volunteer maintainer to start.
So my suggestion for prioritisation:
1. The **diagnostic** (option 1) remains the highest value per effort and is
unaffected by any of this.
2. If a shim is shipped, it should be **opt-in** like `legacyCommandSupport`
in #16011, and its documentation should state plainly that it fixes resolution
only, with binary compatibility still per-plugin.
3. The mapping table above is a starting point but is incomplete - it covers
only the coordinates these two plugins needed, and the renames are not
uniformly 1:1 (`grails-plugin-domain-class` to `grails-domain-class`,
`grails-plugin-mimetypes` to `grails-mimetypes`).
Either way, the workaround above is usable by affected applications today,
which may be worth documenting even if no shim ships.
--
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]
