Gradle 9.1+ doesn't allow exclusiveContent in pluginManagement repositories

[vthacker]

Description

Gradle 9.1+ doesn't allow exclusiveContent in pluginManagement repositories. I recently cloned the repo on my work laptop, and was unable to run any gradle tasks.

java -version
openjdk version "25" 2025-09-16 LTS
...

./gradlew
Starting a Gradle Daemon (subsequent builds will be faster)

[Incubating] Problems report is available at: file:///Users/varunthacker/code/lucene/build/reports/problems/problems-report.html

FAILURE: Build failed with an exception.

* What went wrong:
A problem occurred configuring root project 'lucene-root'.
> When using exclusive repository content in 'settings.pluginManagement.repositories', you cannot add repositories to 'buildscript.repositories'.
  For more information, please refer to https://docs.gradle.org/9.1.0/userguide/declaring_repositories.html#declaring_content_exclusively_found_in_one_repository in the Gradle documentation.

[github-actions]

This PR does not have an entry in lucene/CHANGES.txt. Consider adding one. If the PR doesn't need a changelog entry, then add the skip-changelog label to it and you will stop receiving this reminder on future updates to the PR.

[vthacker]

filter is only available within the exclusiveContent block.

Using content { includeGroup "org.eclipse.jdt" } instead for filtering

[dweiss]

Wait... so why does it work for everyone else? I'm confused.

[dweiss]

I can't reproduce what you're seeing. I've removed my ~/.gradle/caches, I set up a clean clone. It just works fine for me. Strange.

[dweiss]

I also ran this on a clean container - this is without any caches - https://github.com/dweiss/lucene/actions/runs/19027077595/job/54332581482

[dweiss]

I would like to get to the bottom of why it works for everyone but you first, before we apply this change.

[dweiss]

No matter what I do, I can't reproduce this problem on github or my machine. I wonder what's different about your laptop, @vthacker

[vthacker]

No matter what I do, I can't reproduce this problem on github or my machine. I wonder what's different about your laptop, @vthacker

I've asked some other folks to try internally and see if they can repro it. Maybe it's the JDK we use?

For me, I can still repro against main. killed any gradle daemons just to be safe.

[dweiss]

What does it say when you run ./gradlew --stacktrace --info? Can you post a (sanitized) log here?

[vthacker]

Sorry for wasting your time! This was caused because we have a custom ~/.gradle/init.gradle script that sets up internal repositories. That doesn't work with gradle 9.1+ but the error message made it sound like it's a lucene gradle task issue.

Just by pointing to a new gradle home fixed the problem.

GRADLE_USER_HOME=~/.gradle_asf/ ./gradlew

[vthacker]

I was able to incorporate that into my workflow by doing

brew install direnv;eval "$(direnv hook zsh)"

Create a .envrc file in the project root: export GRADLE_USER_HOME=~/.gradle_asf/

direnv allow

Just need to add .envrc to the gitignore

[dweiss]

Thank you! It really looked like a heisenbug. The good thing is that this is only needed as a temporary measure until the next quarterly ecj version is released. I'll take a second look at your patch - I recall filtering isn't really the same as exclusive content - there were some nuances there that caused it to be implemented the way it is... I can't remember what it was though.

[dweiss]

Just need to add .envrc to the gitignore

Feel free to. I don't think anybody will mind.

[vthacker]

Feel free to. I don't think anybody will mind.

#15404

[dweiss]

Ok, I see the difference - the exclusive content will guarantee the artifacts come only from the declared repository (and will not check for any fallback anywhere else). A regular repo with a filter allows for the artifact to be downloaded from other repositories, if it exists there. If I recall right, once an artifact was resolved from repository A, gradle insisted on downloading any other version from the same repository - this failed if you had ecj downloaded from maven central and we then switched to our own patched ivy repo. I believe this is the reason the exclusive content block is there.

If it doesn't bother you to use that direnv hack then I suggest we leave it as it is now. The problem should be gone in ~1 month when new ecj is released.

[vthacker]

Yeah I think we can close this out. it's not something everyone will run into, and likely we won't need the patched ivy repo in the coming months.