feat!: make callsite caching the default and publish invokedynamic under a classifier by codeconsole · Pull Request #16170 · apache/grails-core

codeconsole · 2026-08-18T23:16:16Z

Rebased onto latest 8.0.x (d0c68dc, which brings Groovy 5.1.0) and reworked to the design the Grails team asked for: the main artifact is the callsite-caching flavour, and invokedynamic ships under the indy classifier.

What an application sees

Nothing, unless it opts in. grails.indy defaults to false, exactly as 7.x behaved, and every Grails module and plugin publishes its main artifact compiled that way.

An application that wants invokedynamic gets it for its own classes and its dependencies:

grails {
    indy = true
    indyModules = ['org.apache.grails:grails-core', 'com.example:my-plugin']
}

Dependencies left off the list keep their main artifact. That is safe on the JVM — the two flavours interoperate on the same classpath — but a native image needs the indy flavour of everything, so an application targeting one lists every Grails module and plugin it uses.

Plugins publish both

A project applying org.apache.grails.gradle.grails-plugin builds both flavours through the new indyJar task, so any application that wants indy can have it. grails.indy no longer affects how a plugin compiles its own sources; plugin authors need to change nothing, and a plugin build that sets indy can drop it.

Why a classifier and not a variant

The previous revision of this PR published the indy jar as a secondary Gradle variant, and CI failed across the board:

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:

A configuration that requests no attributes at all — the shape tck and the CLI companion probe use, here and in other people's builds — finds every variant equally good. No attribute rule repairs it: a disambiguation rule only receives the values candidates declare, so the variant without the attribute never appears among them (consumer=null candidates=[false]), and declaring it on both variants breaks every plain consumer instead.

A plain Maven classifier adds nothing to the published metadata, so the ambiguity is unreachable rather than fixed. Selection is assembled on the consuming side: an application that opts in registers a ComponentMetadataRule deriving a variant from the classifier for the modules it lists. That variant exists only inside the opted-in build, whose schema also carries the rules needed to choose.

Verification

10 functional tests in GrailsIndyVariantsSpec, including the two shapes that broke CI last time — an artifact view constraining nothing, and a configuration with no attributes — both now resolving a single artifact.

On grails-cache, a real plugin module with an ast source set:

	entries	classes	with `invokedynamic`	AST classes
main	56	37	1	5
`-indy`	56	37	11	5

Entry lists identical; only the Groovy call-site bytecode differs. (The 1 in the main jar is makeConcatWithConstants in a .java source file — javac's string concatenation, not a Groovy call site.)

Suite: 188/191. The 3 GroovyPageToolchainSpec failures need a JDK 21 toolchain that is not installed on the machine I ran them on and fail identically on unmodified 8.0.x. codeStyle clean.

Known limitations

indyModules must be listed explicitly. An unguarded rule fails hard trying to fetch e.g. groovy-5.1.0-indy.jar, and platforms fail the same way — grails-bom is a platform every application depends on — so there is no safe group-wide default. Modules advertise their classifier through Grails-Indy-Artifact (mirroring Grails-Cli-Artifact) so the list can later be discovered by a probe rather than written; that discovery is not implemented here.
Component metadata rules do not apply to project dependencies, so a composite or multi-project build always resolves the main artifact.

Reviewer notes

Full ./gradlew build has not been run; grails-cache was built and inspected locally. The indyJar task assembles by unpacking the finished main jar rather than listing source directories — enumerating them omitted the AST classes and staged command/template resources, and reusing the main jar's copy spec imported its duplicatesStrategy. Both were caught only by building a real module, not by the functional tests.

codecov · 2026-08-18T23:22:00Z

Codecov Report

❌ Patch coverage is 0.99010% with 100 lines in your changes missing coverage. Please review.
✅ Project coverage is 27.1621%. Comparing base (d0c68dc) to head (3ce9e88).

Files with missing lines	Patch %	Lines
...rails/gradle/plugin/core/GrailsIndyVariants.groovy	0.0000%	68 Missing ⚠️
...gradle/plugin/core/GrailsIndyClassifierRule.groovy	0.0000%	15 Missing ⚠️
...rails/gradle/plugin/core/GrailsGradlePlugin.groovy	0.0000%	8 Missing ⚠️
...le/plugin/core/GrailsIndyDisambiguationRule.groovy	0.0000%	6 Missing ⚠️
...gradle/plugin/core/GrailsPluginGradlePlugin.groovy	0.0000%	3 Missing ⚠️

Additional details and impacted files

@@                 Coverage Diff                 @@
##                8.0.x     #16170         +/-   ##
===================================================
- Coverage     53.6425%   27.1621%   -26.4803%     
+ Complexity      19783        471      -19312     
===================================================
  Files            2086         78       -2008     
  Lines           99630       4521      -95109     
  Branches        17594        772      -16822     
===================================================
- Hits            53444       1228      -52216     
+ Misses          38542       3084      -35458     
+ Partials         7644        209       -7435

Files with missing lines	Coverage Δ
...g/grails/gradle/plugin/core/GrailsExtension.groovy	`51.9231% <100.0000%> (+0.9427%)`	⬆️
...gradle/plugin/core/GrailsPluginGradlePlugin.groovy	`0.0000% <0.0000%> (ø)`
...le/plugin/core/GrailsIndyDisambiguationRule.groovy	`0.0000% <0.0000%> (ø)`
...rails/gradle/plugin/core/GrailsGradlePlugin.groovy	`0.0000% <0.0000%> (ø)`
...gradle/plugin/core/GrailsIndyClassifierRule.groovy	`0.0000% <0.0000%> (ø)`
...rails/gradle/plugin/core/GrailsIndyVariants.groovy	`0.0000% <0.0000%> (ø)`

... and 2011 files with indirect coverage changes

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

codeconsole · 2026-08-19T02:10:59Z

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:

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.

Groovy compiles dynamic calls either as invokedynamic or as call-site caching bytecode. Which is faster depends on the application, but the choice was previously made once at compile time and could not reach the framework and plugin jars an application already depends on. Framework modules and Grails plugins now publish their classes twice: a default artifact using Groovy's own invokedynamic default, and a `noindy` classifier artifact compiled without it. An application sets `grails.indy` and the choice propagates across the whole dependency graph. Selection goes through Gradle Module Metadata rather than the classifier alone. A Maven classifier shares the POM of the main artifact, so asking for one by classifier would pull the default flavour of everything it depends on. The noindy artifact is published as a secondary variant of apiElements and runtimeElements, which inherits their dependencies, so one request applies transitively. Only the noindy variants declare the attribute; the default variants leave it absent. A consumer that never asks for it -- any plain Gradle project that does not apply a Grails plugin -- sees a single candidate and resolves the default artifact as before. Declaring it on both would fail every such build with a variant ambiguity error. grails.indy no longer governs how a plugin compiles its own sources, since a plugin builds both flavours and the application resolving it chooses. Applications are unaffected: the default is still false.

grails.indy defaulted to false, so an application that never configured it compiled with callsite caching. It now defaults to true, matching Groovy's own default, and applications wanting the previous behaviour set it to false explicitly. The setting continues to select which flavour of the framework and plugin artifacts the application resolves, so the default artifact set -- the one almost every application receives -- is the one Groovy would produce. The -PgrailsIndy toggle used by CI now applies only to the application-type projects in this repository; modules applying the grails-plugin plugin build both flavours regardless of it.

Call-site caching bytecode links call sites at runtime and cannot be compiled ahead of time, so a native image needs every artifact on the classpath to be the invokedynamic flavour. Setting indy = false is therefore a choice against native compilation, which the guide did not say.

…shed variant Publishing the noindy jar as a secondary variant of apiElements and runtimeElements made every module ambiguous to a configuration that requests no attributes at all -- the shape the tck and CLI companion probe configurations use -- and CI failed across the board on it. No attribute rule can repair that. A disambiguation rule is handed only the values candidates declare, so the variant without the attribute never appears among them and cannot be preferred; instrumenting the rule shows `consumer=null candidates=[false]`. Declaring the attribute on both variants instead would resolve it here but break every plain consumer of a Grails artifact, which is where this started. The noindy jar is now published as an ordinary Maven classifier and adds nothing to the module's metadata, so no consumer's resolution changes. Selection is assembled on the consuming side: an application that sets indy = false registers a component metadata rule deriving a variant from the classifier for the modules it lists in grails.noindyModules. That variant exists only inside the build that opted in, whose schema carries the rules needed to choose, so the ambiguity is unreachable rather than merely fixed. The list is required because a rule applied to a module that publishes no such classifier -- or to a platform, which publishes no jar -- fails when the missing file is fetched. Modules advertise theirs through the Grails-Noindy-Artifact manifest attribute, mirroring Grails-Cli-Artifact, so the list can later be discovered rather than written. Component metadata rules do not apply to project dependencies, so a composite or multi-project build always resolves the main artifact.

…ssifier Grails 8 compiles applications without invokedynamic, as 7.x did, and every module and plugin publishes its main artifact the same way. The invokedynamic flavour is published alongside it under the `indy` classifier, so an application that wants it can have it throughout rather than only in its own classes -- which is what ahead-of-time native compilation requires, since callsite caching links call sites at runtime and cannot be compiled into a native image. An application opts in by enabling indy and naming the dependencies that publish the classifier: grails { indy = true indyModules = ['org.apache.grails:grails-core'] } Dependencies left off the list keep their main artifact. That is safe on the JVM, where the two flavours interoperate on the same classpath, but a native image needs the indy flavour of everything, so an application targeting one lists every Grails module and plugin it uses. Listing a module that publishes no classifier -- or a platform such as grails-bom, which publishes no jar -- fails when the missing file is fetched, so modules advertise theirs through the Grails-Indy-Artifact manifest attribute. grails.indy no longer governs how a plugin compiles its own sources: a plugin builds both flavours through the new indyJar task and the resolving application chooses. The indy jar is assembled by unpacking the finished main jar and layering the invokedynamic classes over it. Enumerating the source directories instead omitted the AST classes a plugin copies in from a separate source set along with its staged command and template resources, and reusing the main jar's copy spec imported that task's duplicatesStrategy with it. Unpacking keeps the two artifacts identical by construction, whatever the build contributed.

testlens-app · 2026-08-20T00:33:14Z

🚨 TestLens detected 128 failed tests 🚨

Here is what you can do:

Inspect the test failures carefully.
If you are convinced that some of the tests are flaky, you can mute them below.
Finally, trigger a rerun by checking the rerun checkbox.

Test Summary

CI - Groovy Joint Validation Build / Build Grails with Groovy snapshot (shard 0) > :grails-test-examples-app1:integrationTest

Test	Runs	Flakiness
ForwardingSpec > Test forwarding to an action which returns a Map	❌ ✅	1% 🟡

CI - Groovy Joint Validation Build / Build Grails with Groovy snapshot (shard 0) > :grails-test-examples-mongodb-hibernate5:test

Test	Runs	Flakiness
BookFongoSpec > Test GORM access	❌ ❌	0% 🟢

CI - Groovy Joint Validation Build / Build Grails with Groovy snapshot (shard 0) > :grails-test-suite-persistence:test

Test	Runs	Flakiness
GrailsWebDataBinderSpec > Test Map constructor fallback binds unconfigured properties but not bindable false by default	❌ ❌	0% 🟢
GrailsWebDataBinderSpec > Test Map constructor fallback remains permissive for explicit bind-all	❌ ❌	0% 🟢
GrailsWebDataBinderSpec > Test Map constructor fallback remains permissive in compatibility mode	❌ ❌	0% 🟢

CI - Groovy Joint Validation Build / Build Grails with Groovy snapshot (shard 1) > :grails-data-mongodb-core:test

Test	Runs	Flakiness
MongoConnectionSourcesSpec > Test persist and retrieve entities with multi tenancy	❌ 🚫	0% 🟢
ReadConcernArgumentSpec > Test save with write concern	❌ 🚫	0% 🟢

CI - Groovy Joint Validation Build / Build Grails with Groovy snapshot (shard 1) > :grails-data-mongodb-core:test (first 40 of 99)

Test	Runs	Flakiness
AssignedIdentifierSpec > Test that entities can be saved, retrieved and updated with assigned ids	❌ ❌	0% 🟢
AssignedIdentifierSpec > Test that saving a second object with an assigned identifier produces an error	❌ ❌	0% 🟢
BasicCollectionTypeSpec > Test persist basic collection types	❌ ❌	0% 🟢
BatchUpdateDeleteSpec > Test that batch delete works	❌ ❌	0% 🟢
BatchUpdateDeleteSpec > Test that batch update works	❌ ❌	0% 🟢
BatchUpdateDeleteSpec > Test that batch update works with domain properties	❌ ❌	0% 🟢
BrokenManyToManyAssociationSpec > Perform a cascading delete on a broken many-to-many relationship	❌ ❌	0% 🟢
CascadeDeleteOneToOneSpec > Test delete doesnt cascade if no belongsTo	❌ ❌	0% 🟢
CircularBidirectionalOneToManySpec > Test that deleting a child doesn't not delete the parent in a circular association	❌ ❌	0% 🟢
CircularOneToManySpec > Test that deleting a child doesn't not delete the parent in a circular association	❌ ❌	0% 🟢
CriteriaBuilderSpec > Test count distinct projection	❌ ❌	0% 🟢
CriteriaBuilderSpec > Test obtain association entity using property projection	❌ ❌	0% 🟢
CrossLayerMultiDataSourceSpec > data service delete reflected in domain API count	❌ ❌	0% 🟢
CrossLayerMultiDataSourceSpec > domain and service counts match on secondary	❌ ❌	0% 🟢
CrossLayerMultiTenantMultiDataSourceSpec > tenant isolation consistent across layers	❌ ❌	0% 🟢
DataServiceConnectionRoutingSpec > interface service: save routes to secondary datasource	❌ ❌	0% 🟢
DataServiceConnectionRoutingSpec > save routes to secondary datasource	❌ ❌	0% 🟢
DataServiceConnectionRoutingSpec > secondary data is not visible on default datasource	❌ ❌	0% 🟢
DeleteAllSpec > Test deleteAll on a where query converts identifier types	❌ ❌	0% 🟢
DeleteAllSpec > Test that many objects can be deleted at once using multiple arguments	❌ ❌	0% 🟢
DeleteAllSpec > Test that many objects can be deleted at once using multiple arguments and flushes	❌ ❌	0% 🟢
DeleteAllSpec > Test that many objects can be deleted using an iterable	❌ ❌	0% 🟢
DeleteAllSpec > Test that many objects can be deleted using an iterable and flushes	❌ ❌	0% 🟢
DetachedCriteriaSpec > Test deleteAll method	❌ ❌	0% 🟢
DetachedCriteriaSpec > Test deleteAll method on detached criteria with empty criteria	❌ ❌	0% 🟢
DetachedCriteriaSpec > Test updateAll method	❌ ❌	0% 🟢
DirtyCheckingAfterListenerSpec > test state change from listener update the object	❌ ❌	0% 🟢
DomainEventsSpec > Test multi-delete events	❌ ❌	0% 🟢
DomainMultiDataSourceSpec > count on secondary datasource via domain API	❌ ❌	0% 🟢
DomainMultiDataSourceSpec > default data not visible on secondary via domain API	❌ ❌	0% 🟢
DomainMultiDataSourceSpec > delete from secondary datasource via domain API	❌ ❌	0% 🟢
DomainMultiDataSourceSpec > save to secondary datasource via domain API	❌ ❌	0% 🟢
DomainMultiDataSourceSpec > secondary data not visible on default via domain API	❌ ❌	0% 🟢
DomainMultiTenantMultiDataSourceSpec > count scoped to tenant on secondary via domain API	❌ ❌	0% 🟢
DomainMultiTenantMultiDataSourceSpec > delete with tenant isolation on secondary via domain API	❌ ❌	0% 🟢
DomainMultiTenantMultiDataSourceSpec > save with tenant isolation on secondary via domain API	❌ ❌	0% 🟢
DomainMultiTenantMultiDataSourceSpec > tenant1 data not visible to tenant2 via domain API	❌ ❌	0% 🟢
EmbeddedWithNonEmbeddedAssociationsSpec > Test that embedded collections can have non-embedded associations	❌ ❌	0% 🟢
EmbeddedWithNonEmbeddedCollectionsSpec > Test that embedded collections can have non-embedded collections	❌ ❌	0% 🟢
FindNativeSpec > test native find method	❌ ❌	0% 🟢

CI - Groovy Joint Validation Build / Build Grails with Groovy snapshot (shard 1) > :grails-test-examples-mongodb-hibernate5:integrationTest

Test	Runs	Flakiness
BookControllerSpec > Test list books	❌ ❌	0% 🟢

CI - Groovy Joint Validation Build / Build Grails with Groovy snapshot (shard 2) > :grails-data-mongodb-spring-boot:test

Test	Runs	Flakiness
MongoDbGormAutoConfigurationSpec > Test that GORM is correctly configured	❌ ❌	0% 🟢

CI - Groovy Joint Validation Build / Build Grails with Groovy snapshot (shard 2) > :grails-data-mongodb-spring-data:test

Test	Runs	Flakiness
UnifiedMongoTransactionSpec > test a GORM save and a Spring Data write commit together in one transaction	❌ ❌	0% 🟢
UnifiedMongoTransactionSpec > test a GORM save and a Spring Data write roll back together when the transaction fails	❌ ❌	0% 🟢
UnifiedMongoTransactionSpec > test a per-transaction timeout on the unified manager is rejected and binds no Spring Data resource	❌ ❌	0% 🟢
UnifiedMongoTransactionSpec > test sequential unified transactions each commit without leaking the shared session or holder	❌ ❌	0% 🟢
UnifiedMongoTransactionSpec > test the shared database factory does not close GORM's MongoClient	❌ ❌	0% 🟢

CI - Groovy Joint Validation Build / Build Grails with Groovy snapshot (shard 2) > :grails-test-examples-mongodb-base:test

Test	Runs	Flakiness
BookUnitSpec > Test GORM access	❌ ❌	0% 🟢
LocalMongoUnitSpec > Test GORM access	❌ ❌	0% 🟢

CI - Groovy Joint Validation Build / Build Grails with Groovy snapshot (shard 2) > :grails-test-examples-mongodb-database-per-tenant:integrationTest

Test	Runs	Flakiness
BookSpec > Test database per tenant	❌ ❌	0% 🟢

CI / Build Grails-Core (Ubuntu JDK 21) > :grails-test-suite-persistence:test

Test	Runs	Flakiness
GrailsWebDataBinderSpec > Test Map constructor fallback binds unconfigured properties but not bindable false by default	❌	0% 🟢
GrailsWebDataBinderSpec > Test Map constructor fallback remains permissive for explicit bind-all	❌	0% 🟢
GrailsWebDataBinderSpec > Test Map constructor fallback remains permissive in compatibility mode	❌	0% 🟢

CI / Build Grails-Core (Ubuntu JDK 25) > :grails-test-suite-persistence:test

Test	Runs	Flakiness
GrailsWebDataBinderSpec > Test Map constructor fallback binds unconfigured properties but not bindable false by default	❌	0% 🟢
GrailsWebDataBinderSpec > Test Map constructor fallback remains permissive for explicit bind-all	❌	0% 🟢
GrailsWebDataBinderSpec > Test Map constructor fallback remains permissive in compatibility mode	❌	0% 🟢

CI / Build Grails-Core (Windows JDK 25 shard 0) > :grails-test-suite-persistence:test

Test	Runs	Flakiness
GrailsWebDataBinderSpec > Test Map constructor fallback binds unconfigured properties but not bindable false by default	❌	0% 🟢
GrailsWebDataBinderSpec > Test Map constructor fallback remains permissive for explicit bind-all	❌	0% 🟢
GrailsWebDataBinderSpec > Test Map constructor fallback remains permissive in compatibility mode	❌	0% 🟢

CI / Build Grails-Core (macOS JDK 21) > :grails-test-suite-persistence:test

Test	Runs	Flakiness
GrailsWebDataBinderSpec > Test Map constructor fallback binds unconfigured properties but not bindable false by default	❌	0% 🟢
GrailsWebDataBinderSpec > Test Map constructor fallback remains permissive for explicit bind-all	❌	0% 🟢
GrailsWebDataBinderSpec > Test Map constructor fallback remains permissive in compatibility mode	❌	0% 🟢

CI / Build Grails-Core Rerunning all Tasks (Ubuntu JDK 21 shard 0) > :grails-test-suite-persistence:test

Test	Runs	Flakiness
GrailsWebDataBinderSpec > Test Map constructor fallback binds unconfigured properties but not bindable false by default	❌	0% 🟢
GrailsWebDataBinderSpec > Test Map constructor fallback remains permissive for explicit bind-all	❌	0% 🟢
GrailsWebDataBinderSpec > Test Map constructor fallback remains permissive in compatibility mode	❌	0% 🟢

🏷️ Commit: 3ce9e88
▶️ Tests: 61583 executed
⚪️ Checks: 77/77 completed

Test Failures (first 10 of 128)

BookFongoSpec > Test GORM access (:grails-test-examples-mongodb-hibernate5:test in CI - Groovy Joint Validation Build / Build Grails with Groovy snapshot (shard 0))

Condition failed with Exception:

Book.count() == 1
|    |
|    groovy.lang.MissingPropertyException: No such property: log for class: functional.tests.Book
|    Possible solutions: id, DB, all
|    	at org.grails.datastore.gorm.GormStaticApi.propertyMissing(GormStaticApi.groovy:218)
|    	at org.grails.datastore.gorm.GormStaticApi.count_closure10(GormStaticApi.groovy:385)
|    	at org.grails.datastore.mapping.core.DatastoreUtils.execute(DatastoreUtils.java:334)
|    	at org.grails.datastore.gorm.AbstractGormApi.execute(AbstractGormApi.groovy:164)
|    	at org.grails.datastore.gorm.GormStaticApi.count(GormStaticApi.groovy:381)
|    	at org.grails.datastore.gorm.GormEntity$Trait$Helper.count(GormEntity.groovy:733)
|    	at functional.tests.BookFongoSpec.Test GORM access(BookFongoSpec.groovy:63)
class functional.tests.Book

	at functional.tests.BookFongoSpec.Test GORM access(BookFongoSpec.groovy:63)
Caused by: groovy.lang.MissingPropertyException: No such property: log for class: functional.tests.Book
Possible solutions: id, DB, all
	at org.grails.datastore.gorm.GormStaticApi.propertyMissing(GormStaticApi.groovy:218)
	at org.grails.datastore.gorm.GormStaticApi.count_closure10(GormStaticApi.groovy:385)
	at org.grails.datastore.mapping.core.DatastoreUtils.execute(DatastoreUtils.java:334)
	at org.grails.datastore.gorm.AbstractGormApi.execute(AbstractGormApi.groovy:164)
	at org.grails.datastore.gorm.GormStaticApi.count(GormStaticApi.groovy:381)
	at org.grails.datastore.gorm.GormEntity$Trait$Helper.count(GormEntity.groovy:733)
	... 1 more

GrailsWebDataBinderSpec > Test Map constructor fallback binds unconfigured properties but not bindable false by default (:grails-test-suite-persistence:test in CI - Groovy Joint Validation Build / Build Grails with Groovy snapshot (shard 0))

Condition failed with Exception:

holder.values.first.name == 'Default'
|      |      |
|      null   java.lang.NullPointerException: Cannot get property 'first' on null object
|             	at grails.web.databinding.GrailsWebDataBinderSpec.Test Map constructor fallback binds unconfigured properties but not bindable false by default(GrailsWebDataBinderSpec.groovy:627)
<grails.web.databinding.SecureMapConstructorHolder@62878d7c values=inaccessible arrayValues=inaccessible grails_validation_Validateable__beforeValidateHelper=inaccessible grails_validation_Validateable__errors=inaccessible>

	at grails.web.databinding.GrailsWebDataBinderSpec.Test Map constructor fallback binds unconfigured properties but not bindable false by default(GrailsWebDataBinderSpec.groovy:627)
Caused by: java.lang.NullPointerException: Cannot get property 'first' on null object
	... 1 more

GrailsWebDataBinderSpec > Test Map constructor fallback remains permissive for explicit bind-all (:grails-test-suite-persistence:test in CI - Groovy Joint Validation Build / Build Grails with Groovy snapshot (shard 0))

Condition failed with Exception:

holder.values.first.name == 'Explicit'
|      |      |
|      null   java.lang.NullPointerException: Cannot get property 'first' on null object
|             	at grails.web.databinding.GrailsWebDataBinderSpec.Test Map constructor fallback remains permissive for explicit bind-all(GrailsWebDataBinderSpec.groovy:644)
<grails.web.databinding.SecureMapConstructorHolder@7095b688 values=inaccessible arrayValues=inaccessible grails_validation_Validateable__beforeValidateHelper=inaccessible grails_validation_Validateable__errors=inaccessible>

	at grails.web.databinding.GrailsWebDataBinderSpec.Test Map constructor fallback remains permissive for explicit bind-all(GrailsWebDataBinderSpec.groovy:644)
Caused by: java.lang.NullPointerException: Cannot get property 'first' on null object
	... 1 more

GrailsWebDataBinderSpec > Test Map constructor fallback remains permissive in compatibility mode (:grails-test-suite-persistence:test in CI - Groovy Joint Validation Build / Build Grails with Groovy snapshot (shard 0))

Condition failed with Exception:

holder.values.first.name == 'Legacy'
|      |      |
|      null   java.lang.NullPointerException: Cannot get property 'first' on null object
|             	at grails.web.databinding.GrailsWebDataBinderSpec.Test Map constructor fallback remains permissive in compatibility mode(GrailsWebDataBinderSpec.groovy:606)
<grails.web.databinding.SecureMapConstructorHolder@6c92a59d values=inaccessible arrayValues=inaccessible grails_validation_Validateable__beforeValidateHelper=inaccessible grails_validation_Validateable__errors=inaccessible>

	at grails.web.databinding.GrailsWebDataBinderSpec.Test Map constructor fallback remains permissive in compatibility mode(GrailsWebDataBinderSpec.groovy:606)
Caused by: java.lang.NullPointerException: Cannot get property 'first' on null object
	... 1 more

AssignedIdentifierSpec > Test that entities can be saved, retrieved and updated with assigned ids (:grails-data-mongodb-core:test in CI - Groovy Joint Validation Build / Build Grails with Groovy snapshot (shard 1))

Condition failed with Exception:

River.count() == 0
|     |
|     groovy.lang.MissingPropertyException: No such property: log for class: org.grails.datastore.gorm.mongo.River
|     Possible solutions: id, DB, all
|     	at org.grails.datastore.gorm.GormStaticApi.propertyMissing(GormStaticApi.groovy:218)
|     	at org.grails.datastore.gorm.GormStaticApi.count_closure10(GormStaticApi.groovy:385)
|     	at org.grails.datastore.mapping.core.DatastoreUtils.execute(DatastoreUtils.java:334)
|     	at org.grails.datastore.gorm.AbstractGormApi.execute(AbstractGormApi.groovy:164)
|     	at org.grails.datastore.gorm.GormStaticApi.count(GormStaticApi.groovy:381)
|     	at org.grails.datastore.gorm.GormEntity$Trait$Helper.count(GormEntity.groovy:733)
|     	at org.grails.datastore.gorm.mongo.AssignedIdentifierSpec.Test that entities can be saved, retrieved and updated with assigned ids(AssignedIdentifierSpec.groovy:62)
class org.grails.datastore.gorm.mongo.River

	at org.grails.datastore.gorm.mongo.AssignedIdentifierSpec.Test that entities can be saved, retrieved and updated with assigned ids(AssignedIdentifierSpec.groovy:62)
Caused by: groovy.lang.MissingPropertyException: No such property: log for class: org.grails.datastore.gorm.mongo.River
Possible solutions: id, DB, all
	at org.grails.datastore.gorm.GormStaticApi.propertyMissing(GormStaticApi.groovy:218)
	at org.grails.datastore.gorm.GormStaticApi.count_closure10(GormStaticApi.groovy:385)
	at org.grails.datastore.mapping.core.DatastoreUtils.execute(DatastoreUtils.java:334)
	at org.grails.datastore.gorm.AbstractGormApi.execute(AbstractGormApi.groovy:164)
	at org.grails.datastore.gorm.GormStaticApi.count(GormStaticApi.groovy:381)
	at org.grails.datastore.gorm.GormEntity$Trait$Helper.count(GormEntity.groovy:733)
	... 1 more

AssignedIdentifierSpec > Test that saving a second object with an assigned identifier produces an error (:grails-data-mongodb-core:test in CI - Groovy Joint Validation Build / Build Grails with Groovy snapshot (shard 1))

groovy.lang.MissingPropertyException: No such property: log for class: org.grails.datastore.gorm.mongo.River
Possible solutions: id, DB, all
	at org.grails.datastore.gorm.GormStaticApi.propertyMissing(GormStaticApi.groovy:218)
	at org.grails.datastore.gorm.GormStaticApi.count_closure10(GormStaticApi.groovy:385)
	at org.grails.datastore.mapping.core.DatastoreUtils.execute(DatastoreUtils.java:334)
	at org.grails.datastore.gorm.AbstractGormApi.execute(AbstractGormApi.groovy:164)
	at org.grails.datastore.gorm.GormStaticApi.count(GormStaticApi.groovy:381)
	at org.grails.datastore.gorm.GormEntity$Trait$Helper.count(GormEntity.groovy:733)
	at org.grails.datastore.gorm.mongo.AssignedIdentifierSpec.Test that saving a second object with an assigned identifier produces an error_closure1(AssignedIdentifierSpec.groovy:92)
	at org.grails.datastore.gorm.GormStaticApi.withNewSession_closure23(GormStaticApi.groovy:767)
	at org.grails.datastore.mapping.core.DatastoreUtils.executeWithNewSession(DatastoreUtils.java:371)
	at org.grails.datastore.gorm.GormStaticApi.withNewSession(GormStaticApi.groovy:766)
	at org.grails.datastore.gorm.GormEntity$Trait$Helper.withNewSession(GormEntity.groovy:1157)
	at org.grails.datastore.gorm.mongo.AssignedIdentifierSpec.Test that saving a second object with an assigned identifier produces an error(AssignedIdentifierSpec.groovy:89)

BasicCollectionTypeSpec > Test persist basic collection types (:grails-data-mongodb-core:test in CI - Groovy Joint Validation Build / Build Grails with Groovy snapshot (shard 1))

Condition failed with Exception:

MyCollections.count() == 0
|             |
|             groovy.lang.MissingPropertyException: No such property: log for class: org.grails.datastore.gorm.mongo.MyCollections
|             Possible solutions: id, DB, all
|             	at org.grails.datastore.gorm.GormStaticApi.propertyMissing(GormStaticApi.groovy:218)
|             	at org.grails.datastore.gorm.GormStaticApi.count_closure10(GormStaticApi.groovy:385)
|             	at org.grails.datastore.mapping.core.DatastoreUtils.execute(DatastoreUtils.java:334)
|             	at org.grails.datastore.gorm.AbstractGormApi.execute(AbstractGormApi.groovy:164)
|             	at org.grails.datastore.gorm.GormStaticApi.count(GormStaticApi.groovy:381)
|             	at org.grails.datastore.gorm.GormEntity$Trait$Helper.count(GormEntity.groovy:733)
|             	at org.grails.datastore.gorm.mongo.BasicCollectionTypeSpec.Test persist basic collection types(BasicCollectionTypeSpec.groovy:87)
class org.grails.datastore.gorm.mongo.MyCollections

	at org.grails.datastore.gorm.mongo.BasicCollectionTypeSpec.Test persist basic collection types(BasicCollectionTypeSpec.groovy:87)
Caused by: groovy.lang.MissingPropertyException: No such property: log for class: org.grails.datastore.gorm.mongo.MyCollections
Possible solutions: id, DB, all
	at org.grails.datastore.gorm.GormStaticApi.propertyMissing(GormStaticApi.groovy:218)
	at org.grails.datastore.gorm.GormStaticApi.count_closure10(GormStaticApi.groovy:385)
	at org.grails.datastore.mapping.core.DatastoreUtils.execute(DatastoreUtils.java:334)
	at org.grails.datastore.gorm.AbstractGormApi.execute(AbstractGormApi.groovy:164)
	at org.grails.datastore.gorm.GormStaticApi.count(GormStaticApi.groovy:381)
	at org.grails.datastore.gorm.GormEntity$Trait$Helper.count(GormEntity.groovy:733)
	... 1 more

BatchUpdateDeleteSpec > Test that batch delete works (:grails-data-mongodb-core:test in CI - Groovy Joint Validation Build / Build Grails with Groovy snapshot (shard 1))

Condition failed with Exception:

Plant.count() == 6
|     |
|     groovy.lang.MissingPropertyException: No such property: log for class: grails.gorm.tests.Plant
|     Possible solutions: id, DB, all
|     	at org.grails.datastore.gorm.GormStaticApi.propertyMissing(GormStaticApi.groovy:218)
|     	at org.grails.datastore.gorm.GormStaticApi.count_closure10(GormStaticApi.groovy:385)
|     	at org.grails.datastore.mapping.core.DatastoreUtils.execute(DatastoreUtils.java:334)
|     	at org.grails.datastore.gorm.AbstractGormApi.execute(AbstractGormApi.groovy:164)
|     	at org.grails.datastore.gorm.GormStaticApi.count(GormStaticApi.groovy:381)
|     	at org.grails.datastore.gorm.GormEntity$Trait$Helper.count(GormEntity.groovy:733)
|     	at org.grails.datastore.gorm.mongo.BatchUpdateDeleteSpec.Test that batch delete works(BatchUpdateDeleteSpec.groovy:44)
class grails.gorm.tests.Plant

	at org.grails.datastore.gorm.mongo.BatchUpdateDeleteSpec.Test that batch delete works(BatchUpdateDeleteSpec.groovy:44)
Caused by: groovy.lang.MissingPropertyException: No such property: log for class: grails.gorm.tests.Plant
Possible solutions: id, DB, all
	at org.grails.datastore.gorm.GormStaticApi.propertyMissing(GormStaticApi.groovy:218)
	at org.grails.datastore.gorm.GormStaticApi.count_closure10(GormStaticApi.groovy:385)
	at org.grails.datastore.mapping.core.DatastoreUtils.execute(DatastoreUtils.java:334)
	at org.grails.datastore.gorm.AbstractGormApi.execute(AbstractGormApi.groovy:164)
	at org.grails.datastore.gorm.GormStaticApi.count(GormStaticApi.groovy:381)
	at org.grails.datastore.gorm.GormEntity$Trait$Helper.count(GormEntity.groovy:733)
	... 1 more

BatchUpdateDeleteSpec > Test that batch update works (:grails-data-mongodb-core:test in CI - Groovy Joint Validation Build / Build Grails with Groovy snapshot (shard 1))

Condition failed with Exception:

Plant.count() == 6
|     |
|     groovy.lang.MissingPropertyException: No such property: log for class: grails.gorm.tests.Plant
|     Possible solutions: id, DB, all
|     	at org.grails.datastore.gorm.GormStaticApi.propertyMissing(GormStaticApi.groovy:218)
|     	at org.grails.datastore.gorm.GormStaticApi.count_closure10(GormStaticApi.groovy:385)
|     	at org.grails.datastore.mapping.core.DatastoreUtils.execute(DatastoreUtils.java:334)
|     	at org.grails.datastore.gorm.AbstractGormApi.execute(AbstractGormApi.groovy:164)
|     	at org.grails.datastore.gorm.GormStaticApi.count(GormStaticApi.groovy:381)
|     	at org.grails.datastore.gorm.GormEntity$Trait$Helper.count(GormEntity.groovy:733)
|     	at org.grails.datastore.gorm.mongo.BatchUpdateDeleteSpec.Test that batch update works(BatchUpdateDeleteSpec.groovy:61)
class grails.gorm.tests.Plant

	at org.grails.datastore.gorm.mongo.BatchUpdateDeleteSpec.Test that batch update works(BatchUpdateDeleteSpec.groovy:61)
Caused by: groovy.lang.MissingPropertyException: No such property: log for class: grails.gorm.tests.Plant
Possible solutions: id, DB, all
	at org.grails.datastore.gorm.GormStaticApi.propertyMissing(GormStaticApi.groovy:218)
	at org.grails.datastore.gorm.GormStaticApi.count_closure10(GormStaticApi.groovy:385)
	at org.grails.datastore.mapping.core.DatastoreUtils.execute(DatastoreUtils.java:334)
	at org.grails.datastore.gorm.AbstractGormApi.execute(AbstractGormApi.groovy:164)
	at org.grails.datastore.gorm.GormStaticApi.count(GormStaticApi.groovy:381)
	at org.grails.datastore.gorm.GormEntity$Trait$Helper.count(GormEntity.groovy:733)
	... 1 more

BatchUpdateDeleteSpec > Test that batch update works with domain properties (:grails-data-mongodb-core:test in CI - Groovy Joint Validation Build / Build Grails with Groovy snapshot (shard 1))

Condition failed with Exception:

BatchUser.count() == 3
|         |
|         groovy.lang.MissingPropertyException: No such property: log for class: org.grails.datastore.gorm.mongo.BatchUser
|         Possible solutions: id, DB, all
|         	at org.grails.datastore.gorm.GormStaticApi.propertyMissing(GormStaticApi.groovy:218)
|         	at org.grails.datastore.gorm.GormStaticApi.count_closure10(GormStaticApi.groovy:385)
|         	at org.grails.datastore.mapping.core.DatastoreUtils.execute(DatastoreUtils.java:334)
|         	at org.grails.datastore.gorm.AbstractGormApi.execute(AbstractGormApi.groovy:164)
|         	at org.grails.datastore.gorm.GormStaticApi.count(GormStaticApi.groovy:381)
|         	at org.grails.datastore.gorm.GormEntity$Trait$Helper.count(GormEntity.groovy:733)
|         	at org.grails.datastore.gorm.mongo.BatchUpdateDeleteSpec.Test that batch update works with domain properties(BatchUpdateDeleteSpec.groovy:98)
class org.grails.datastore.gorm.mongo.BatchUser

	at org.grails.datastore.gorm.mongo.BatchUpdateDeleteSpec.Test that batch update works with domain properties(BatchUpdateDeleteSpec.groovy:98)
Caused by: groovy.lang.MissingPropertyException: No such property: log for class: org.grails.datastore.gorm.mongo.BatchUser
Possible solutions: id, DB, all
	at org.grails.datastore.gorm.GormStaticApi.propertyMissing(GormStaticApi.groovy:218)
	at org.grails.datastore.gorm.GormStaticApi.count_closure10(GormStaticApi.groovy:385)
	at org.grails.datastore.mapping.core.DatastoreUtils.execute(DatastoreUtils.java:334)
	at org.grails.datastore.gorm.AbstractGormApi.execute(AbstractGormApi.groovy:164)
	at org.grails.datastore.gorm.GormStaticApi.count(GormStaticApi.groovy:381)
	at org.grails.datastore.gorm.GormEntity$Trait$Helper.count(GormEntity.groovy:733)
	... 1 more

Rerun Controls (first 20 of 131)

Select tests to mute in this pull request:

Reuse successful test results:

♻️ Only rerun the tests that failed or were muted before

Click the checkbox to trigger a rerun:

Rerun jobs

Learn more about TestLens at testlens.app/docs.

jamesfredley · 2026-08-20T13:54:02Z

@codeconsole #16178 and this PR have a lot of overlap for Grails 8 on Groovy 5. Since Groovy 5 Indy is not fast enough in Grails I am not sure we need to publish the extra modules.

Then on Groovy 6, we will flip everything to Indy, which will be the first time Grails is on Indy, with the exception of the narrow window at the beginning of Grails 7.

github-project-automation Bot added this to Apache Grails Aug 18, 2026

codeconsole mentioned this pull request Aug 18, 2026

feat: keep published artifacts on invokedynamic, let applications choose #16171

Open

codeconsole marked this pull request as draft August 19, 2026 13:28

codeconsole added 5 commits August 19, 2026 23:51

codeconsole force-pushed the feat/indy-dual-artifacts branch from b9ed461 to 3ce9e88 Compare August 20, 2026 00:11

codeconsole changed the title ~~feat: publish Groovy artifacts with and without invokedynamic~~ feat!: make callsite caching the default and publish invokedynamic under a classifier Aug 20, 2026

Navigation Menu

Uh oh!

Uh oh!

feat!: make callsite caching the default and publish invokedynamic under a classifier - #16170

feat!: make callsite caching the default and publish invokedynamic under a classifier#16170
codeconsole wants to merge 5 commits into
apache:8.0.xfrom
codeconsole:feat/indy-dual-artifacts

codeconsole commented Aug 18, 2026 •

edited

Loading

Uh oh!

codecov Bot commented Aug 18, 2026 •

edited

Loading

Uh oh!

codeconsole commented Aug 19, 2026

Uh oh!

testlens-app Bot commented Aug 20, 2026 •

edited

Loading

Uh oh!

jamesfredley commented Aug 20, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Uh oh!

Conversation

codeconsole commented Aug 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What an application sees

Plugins publish both

Why a classifier and not a variant

Verification

Known limitations

Reviewer notes

Uh oh!

codecov Bot commented Aug 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

codeconsole commented Aug 19, 2026

Why it failed

What replaces it

Two limitations, both inherent

Standing recommendation unchanged

Uh oh!

testlens-app Bot commented Aug 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

🚨 TestLens detected 128 failed tests 🚨

Test Summary

CI - Groovy Joint Validation Build / Build Grails with Groovy snapshot (shard 0) > :grails-test-examples-app1:integrationTest

CI - Groovy Joint Validation Build / Build Grails with Groovy snapshot (shard 0) > :grails-test-examples-mongodb-hibernate5:test

CI - Groovy Joint Validation Build / Build Grails with Groovy snapshot (shard 0) > :grails-test-suite-persistence:test

CI - Groovy Joint Validation Build / Build Grails with Groovy snapshot (shard 1) > :grails-data-mongodb-core:test

CI - Groovy Joint Validation Build / Build Grails with Groovy snapshot (shard 1) > :grails-data-mongodb-core:test (first 40 of 99)

CI - Groovy Joint Validation Build / Build Grails with Groovy snapshot (shard 1) > :grails-test-examples-mongodb-hibernate5:integrationTest

CI - Groovy Joint Validation Build / Build Grails with Groovy snapshot (shard 2) > :grails-data-mongodb-spring-boot:test

CI - Groovy Joint Validation Build / Build Grails with Groovy snapshot (shard 2) > :grails-data-mongodb-spring-data:test

CI - Groovy Joint Validation Build / Build Grails with Groovy snapshot (shard 2) > :grails-test-examples-mongodb-base:test

CI - Groovy Joint Validation Build / Build Grails with Groovy snapshot (shard 2) > :grails-test-examples-mongodb-database-per-tenant:integrationTest

CI / Build Grails-Core (Ubuntu JDK 21) > :grails-test-suite-persistence:test

CI / Build Grails-Core (Ubuntu JDK 25) > :grails-test-suite-persistence:test

CI / Build Grails-Core (Windows JDK 25 shard 0) > :grails-test-suite-persistence:test

CI / Build Grails-Core (macOS JDK 21) > :grails-test-suite-persistence:test

CI / Build Grails-Core Rerunning all Tasks (Ubuntu JDK 21 shard 0) > :grails-test-suite-persistence:test

Test Failures (first 10 of 128)

Rerun Controls (first 20 of 131)

Uh oh!

jamesfredley commented Aug 20, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

codeconsole commented Aug 18, 2026 •

edited

Loading

codecov Bot commented Aug 18, 2026 •

edited

Loading

testlens-app Bot commented Aug 20, 2026 •

edited

Loading