jamesfredley opened a new issue, #16125:
URL: https://github.com/apache/grails-core/issues/16125
### Summary
Plugins published against the **pre-Apache `org.grails` coordinates** cannot
be consumed by a Grails 8 application, and the failure is reported as a
resolution error with an **empty version**, which points at nothing actionable:
```
> Could not find org.grails:grails-core:.
Required by:
root project 'seedme' > com.bertramlabs.plugins:seed-me:7.0.0
```
This is not a regression in Grails 8 behaviour - those artifacts genuinely
do not exist under the new group. But it is a direct consequence of the
`org.grails` to `org.apache.grails` rename, it affects a large class of plugins
including ones the community has explicitly asked for, and today there is
nothing in the error, the BOM, or the upgrade guide that tells a user what
actually happened or what to do.
Found while working through the plugins requested in #15044 against
`8.0.0-M5`.
### Grails Version
8.0.0-M5
### Why the version is empty
These plugins do declare versions - indirectly. `seed-me-7.0.0.pom` lists
its Grails dependencies with no version:
```xml
<dependency>
<groupId>org.grails</groupId>
<artifactId>grails-core</artifactId>
<scope>runtime</scope>
...
</dependency>
```
and supplies the versions by importing the **old group's** BOM:
```xml
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.grails</groupId>
<artifactId>grails-bom</artifactId>
<version>7.0.0-M1</version>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
```
So this plugin **was** built for Grails 7 - just against
`org.grails:grails-bom:7.0.0-M1`, published before the GA move to
`org.apache.grails:grails-bom`. When a Grails 8 app consumes it, nothing
manages `org.grails:*` any more, the version resolves to empty, and the build
fails with the message above.
### Affected plugins observed
All of the following fail this way on 8.0.0-M5, each with `Could not find
org.grails:<artifact>:` and an empty version:
| Plugin | Missing coordinates |
|---|---|
| `com.bertramlabs.plugins:seed-me:7.0.0` (requested in #15044) |
`grails-core`, `grails-web-boot`, `grails-dependencies`,
`grails-plugin-domain-class` |
| `com.bertramlabs.plugins:grails-force-ssl:7.0.0` (requested in #15044) |
`grails-web-boot`, `grails-dependencies` |
| `io.github.gpc:asynchronous-mail:3.1.2` (requested in #15044) | old
`org.grails.plugins:mail` line |
| `org.grails.plugins:spring-security-core:7.0.0-M3` |
`grails-datastore-core`, `grails-datastore-gorm`, `grails-events-transform`,
`grails-plugin-mimetypes`, `grails-web-common`, `grails-web-url-mappings`,
`org.grails.plugins:async` |
| `org.grails.plugins:mongodb:9.0.0-M3` | `grails-datastore-core`,
`grails-datastore-gorm`, `grails-datastore-gorm-support` |
Two of these (`seed-me`, `grails-force-ssl`) are plugins users specifically
asked for in the volunteer discussion, so this is the first wall those users
hit.
### Expected Behaviour
Either the legacy coordinates keep resolving to their Apache equivalents, or
the build fails with a message that names the real problem, for example:
```
Plugin com.bertramlabs.plugins:seed-me:7.0.0 depends on the pre-Apache
'org.grails' coordinates
(org.grails:grails-core), which are not published for Grails 8. This plugin
needs to be rebuilt
against org.apache.grails. See <upgrade guide link>.
```
### Actual Behaviour
`Could not find org.grails:grails-core:` with an empty version and no
indication that a group rename is the cause.
### Suggested resolution
In rough order of increasing effort:
1. **Diagnostic only.** Detect a resolution failure for a `org.grails:*`
coordinate with an unresolved version and rewrite the message to explain the
rename and point at the upgrade guide. The Grails Gradle plugin already detects
this exact condition today in a related path - it emits a graceful warning
during CLI companion probing:
```
Could not fully resolve CLI companion probe dependencies for project
seedme; ...
Cause: Could not find org.grails:grails-core:.
```
so the detection point largely exists already.
2. **Document it.** Add a short section to the Grails 8 upgrade guide's
plugin-compatibility notes describing this failure shape, since the error text
is not searchable in any useful way.
3. **Compatibility shim.** Provide opt-in alignment from the legacy
`org.grails:*` coordinates to their `org.apache.grails:*` equivalents, via
Gradle module replacement / component metadata rules shipped by the Grails
Gradle plugin (or relocation metadata). This would be in the same spirit as
`legacyCommandSupport` in #16011 and the proposed
`grails.legacy.holdersDuringDoWithSpring` in #16101 - off by default, opt-in
for migration, and it would let a number of otherwise-abandoned plugins keep
working while their maintainers catch up.
Option 3 needs care: the renamed modules are not always 1:1 (for example
`grails-plugin-domain-class` to `grails-domain-class`,
`grails-plugin-mimetypes` to `grails-mimetypes`), and a Grails 7-era jar may
not be binary compatible with Grails 8 even once it resolves. Options 1 and 2
are safe regardless and would remove most of the confusion on their own.
### Notes
Part of a broader compatibility sweep of released Grails 7 plugins against
8.0.0-M5, alongside #16122, #16123, and #16124. Unlike those three, this one is
not a behavioural regression - it is a discoverability and migration-path gap
created by the group rename.
--
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]
