Plugins built against pre-Apache org.grails coordinates fail on Grails 8 with an empty-version resolution error

[jamesfredley]

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:

<dependency>
  <groupId>org.grails</groupId>
  <artifactId>grails-core</artifactId>
  <scope>runtime</scope>
  ...
</dependency>

and supplies the versions by importing the old group's BOM:

<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 Opt-in backwards compatibility for Grails 7 command plugins on Grails 8 #16011 and the proposed grails.legacy.holdersDuringDoWithSpring in Add opt-in legacy Holder shim for early plugin registration #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.

[jamesfredley]

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:

// 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 Opt-in backwards compatibility for Grails 7 command plugins on Grails 8 #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.

[jamesfredley]

Latest Asynchronous Mail release confirms the same failure

I corrected the earlier audit, which had tested the old asynchronous-mail:3.1.2. The current release is io.github.gpc:asynchronous-mail:4.0.0 (published for the Grails 6 line), and a fresh Grails 8.0.0-M5 application still fails before compilation for the same reason described here.

The published Gradle metadata for 4.0.0 contains versionless runtime dependencies such as:

{
  "group": "org.grails",
  "module": "grails-logging"
}

Its POM imports org.grails:grails-bom:6.2.3 and spring-boot-dependencies:2.7.18. Under the Grails 8 Apache BOM, resolution fails with:

Could not find org.grails:grails-logging:.
Required by: io.github.gpc:asynchronous-mail:4.0.0

The same dependency graph also requests org.grails.plugins:quartz:2.0.13, which is unavailable from the configured repositories, and brings a Grails 6/Groovy 3 dependency stack that conflicts with Grails 8's Groovy 5 stack.

So the prior statement that Asynchronous Mail was never updated was incorrect, but the latest 4.0.0 release still provides another current example of this issue's empty-version pre-Apache coordinate failure. The application never reaches plugin loading or its public integration test.