Configuration phase ordering and laziness help with project extensions

[ianbrandt]

@Vampire

Instead lazily configure the configuration and there do artifacts.add(...) if you can get hold of a PublishArtifact.

If not, maybe try to just do the project.artifacts.add(name, ...) call in a configure closure for the configuration so that the artifact still is only added when the configuration is realized.

Thanks for the tip. I might have thought that’d cause a problem with the ordering of the artifact add, but the second approach is working for me in a minimal reproducer project (I’m not sure how I’d get a hold of a PublishArtifact in my context in order to try the first approach):

• gradle-eager-configuration-realization/buildSrc/src/main/kotlin/extra-configuration.gradle.kts at fa4d6c071da00abbad4c724300774902d5d902db · ianbrandt/gradle-eager-configuration-realization · GitHub
  • Clear gradlew help Output

Unfortunately, I still seem to have some other source of eagerness in my prototype project when I try the same:

• sd-kotlin-spring-talks/build-logic/src/main/kotlin/org/sdkotlin/buildlogic/plugins/resources/ResourceConfigurationVariants.kt at f6c194c8fe5ba3d4cb5ced877635d3eea40b29ae · sdkotlin/sd-kotlin-spring-talks · GitHub
  • Stack Trace

No plugins or anything obvious stands out to my eyes in that stack trace. I’m guessing this is another case where earlier eager API use is queuing the eager configuration. I’ve locally tried setting the workaround properties for the Kotlin Gradle Plugin issues from above, and pulled the JVM Dependency Conflict and Spring Boot plugins completely out of the project, but no change. I’ll keep removing things to see if any make a difference.

[Vampire (Björn Kautler)]

In the stacktrace you do not have the line 72 twice, once for the actual configure lambda start and once further down for the consumable call.
If this would be the case that something else already caused eager realization and thus this is immediately realized and then configured, then you would see the consumable call as start point.
But here you don’t have it, so the realization is triggered after your consumable call.

So you check in the stacktrace for eager api like all or in this case iterator and you land at these lines which cause the realization: gradle/platforms/core-configuration/kotlin-dsl-provider-plugins/src/main/kotlin/org/gradle/kotlin/dsl/provider/plugins/DefaultProjectSchemaProvider.kt at master · gradle/gradle · GitHub