Hey, folks! I face an issue when one adds a reposi...
# community-support
j
Hey, folks! I face an issue when one adds a repository with
exclusiveContent
filters defined twice – none of the repositories is eventually picked for the dependency resolution. Is that an expected/known issue?
Copy code
plugins {
    id("java")
}

repositories {
    mavenCentral {
        exclusiveContent {
            forRepositories(this@mavenCentral)
            filter {
                includeGroup("junit")
                includeGroup("org.hamcrest")
            }
        }
    }
    mavenCentral {
        exclusiveContent {
            forRepositories(this@mavenCentral)
            filter {
                includeGroup("junit")
                includeGroup("org.hamcrest")
            }
        }
    }
}

dependencies {
    testImplementation("junit:junit:4.13.2")
}
This fails with:
Copy code
foo:test: Could not find junit:junit:4.13.2.
Required by:
    project :
1
v
You define two separate repositories and configure for both that the dependency is exclusively present there, what do you expect should happen? 😄 That both repositories happen to point to the same URL is irrelevant for this. That could be intended, like one for snapshots, one for releases and each with separate content filters, ...
j
This is just a simplified example. For performance reasons, I’m providing a custom repository helper to add a more complex Ivy repository with such a filter. By accident, one of the users already called that helper twice, adding the special repository to the project twice and eventually making the resolution fail.
v
Yeah, but my question stays the same. 🙂
Maybe you should make your helper check for the repository before adding it or similar
And either add to it or replace it or do nothing
Depending on what makes most sense in your case
j
This is technically possible, but I’m surprised with the outcome.
v
Again, you define two repositories and configure for each that X is exclusively present in that one. My question was sincere, what would you expect to happen?
j
I’d expect to use both for resolving the given dependency.
v
But you configured that the dependency is exclusively in that repository
That means, in that repository and no other
And that for two different repositories
Why should it resolve from both, when you say it is only available in the one and not in others?
j
Can we have
notThatExclusiveContent
then? 😉
v
I mean, you're welcome to open a feature request to change the logic in that way, then see what the Gradle folks say. But then it would not really be exclusive. Maybe it would make sense to actually fail with a meaningful error if something would be exclusively in two repos though. 🤷‍♂️
j
I want to make sure that one repository won’t be used for searching any other dependencies than requested – as it is supposed to serve just a specific content with fixed group.
Failing works okayish and points to the location where the repository was added lately – but won’t help in finding the other place.
v
The "not that exclusive content" would probably be something like
Copy code
repositories.configureEach {
    if (this is not_my_special_repo) {
        content { 
            exclude...
        }
    }
}
I want to make sure that one repository won’t be used for searching any other dependencies than requested – as it is supposed to serve just a specific content with fixed group.
then exclusive content is wrong anyway
exclusive content means "X is available only in this repository, not in any other repository"
What you want if you picked the right words is a simple
content { include... }
That then means "in this repository you only find X, nothing else"
And that would also then work fine if done twice
The second will just never be asked for anything, as for the matching content the first will be used and unmatching content will not be asked for
So still adding a second time is not that meaningful, but at least would not break anything
j
Oh my, rookie mistake.
Thank you for the explanation – this works exactly as intended. Thanks , Björn!
👌 1