Skip to content

Conversation

@kroune
Copy link

@kroune kroune commented Dec 30, 2025

The reason for this mr is parallel configuration cache issue I encountered in fabric-loom plugin. It can be reproduced by adding

org.gradle.daemon=true
org.gradle.parallel=true
org.gradle.caching=true
org.gradle.configuration-cache=true
org.gradle.configuration-cache.parallel=true

in gradle.properties

I am definitely not a plugin developer, I tried to write a unit test for this to reproduce, but wasn't able to (test passed even though it fails in fabric-loom plugin)

Please DO NOT FORCE PUSH. Don't worry about messy history, it's easier to do code review if we can tell what happened after the review, and force pushing breaks that.

Please make sure that your PR allows edits from maintainers. Sometimes it's faster for us to just fix something than it is to describe how to fix it.

Allow edits from maintainers

After creating the PR, please add a commit that adds a bullet-point under the [Unreleased] section of CHANGES.md, plugin-gradle/CHANGES.md, and plugin-maven/CHANGES.md which includes:

  • a summary of the change
  • either
    • a link to the issue you are resolving (for small changes)
    • a link to the PR you just created (for big changes likely to have discussion)

If your change only affects a build plugin, and not the lib, then you only need to update the plugin-foo/CHANGES.md for that plugin.

If your change affects lib in an end-user-visible way (fixing a bug, updating a version) then you need to update CHANGES.md for both the lib and all build plugins. Users of a build plugin shouldn't have to refer to lib to see changes that affect them.

This makes it easier for the maintainers to quickly release your changes :)

termsOfUseAgree = "yes"
publishing {
onlyIf { providers.environmentVariable('CI').present }
onlyIf { getenv('CI') != null }
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This change is unrelated.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, it just causes a warning for configuration cache. Nothing breaks, but I think code looks cleaner and it doesn't cause a warning

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you paste the warning here?

if (!getProject().getPlugins().hasPlugin(GroovyBasePlugin.class)) {
throw new GradleException(message);
}
final boolean excludeJavaValue = excludeJava;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This might be related, but needs to add a test for verifiing it.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was able to confirm locally that it fixes the issue, but wasn't able to write a working test (it just passed even though it failed in project). If it is really needed I will try to make it work a bit later

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants