mandrachek
October 24, 2024, 6:39pm
1
I have a private repository setup in settings.gradle.kts for pluginManagment.repositories, pluginManagement.buildscript.repositories, and dependencyResolutionManagement.repositories for my buildScript and my project.
Almost all my dependencies are loaded from the configured repository. However, without finding any missing dependencies, and without having gradlePluginPortal() defined, I have a bunch of accesses to repo.gradle.org looking for groovy dependencies.
It appears that repo.gradle.org is blocked by my organization (it’s proxied by the private repo). These downloads fail and break my build. This is with gradle 10 - 10.2.
Why is it attempting to load dependencies from repo.gradle.org , and how can I fix it so it uses the private repository?
mandrachek
October 24, 2024, 6:48pm
2
Actually, it looks like builds are ok, it’s just syncing in Android Studio that throws warnings.
Vampire
October 24, 2024, 11:13pm
3
Iirc this is coming from a semi-hard-coded repository where the sources for the Gradle API are resolved from which also is the reason it only happens on IDE sync.
“semi”, because you can override the repository using GRADLE_LIBS_REPO_OVERRIDE.
mandrachek
October 25, 2024, 12:07am
4
That appears to be correct. However , you cannot set username or password for this repository. So the url can be changed, but my repo requires authentication, so it’s worthless. Apparently someone submitted a PR to fix this by allowing credentials through gradle properties, but it was rejected.
gradle:master ← akiraly:akiraly-master
opened 09:19PM - 15 Oct 23 UTC
Allow overriding the default Gradle library repository through a new Gradle prop… erty called `org.gradle.internal.gradle.libs.repo.override` (previously overriding was only possible through the `GRADLE_LIBS_REPO_OVERRIDE` environment variable).
The Gradle property can be more useful because it can be defined in the build itself (either through gradle.properties or programmatically)
### Context
This can be useful for every project which needs to override the default Gradle library repository (typical in corporate settings, behind a firm firewall). While the environment variable works it is not convenient: each developer has to define the environment variable manually in his/her dev environment. The Gradle property is more practical because it can be defined inside the build and kept together with the rest of the build configuration in the source repository.
### Contributor Checklist
- [X] [Review Contribution Guidelines](https://github.com/gradle/gradle/blob/master/CONTRIBUTING.md)
- [X] Make sure that all commits are [signed off](https://git-scm.com/docs/git-commit#Documentation/git-commit.txt---signoff) to indicate that you agree to the terms of [Developer Certificate of Origin](https://developercertificate.org/).
- [X] Make sure all contributed code can be distributed under the terms of the [Apache License 2.0](https://github.com/gradle/gradle/blob/master/LICENSE), e.g. the code was written by yourself or the original code is licensed under [a license compatible to Apache License 2.0](https://apache.org/legal/resolved.html).
- [X] Check ["Allow edit from maintainers" option](https://help.github.com/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork/) in pull request so that additional changes can be pushed by Gradle team
- [x] Provide integration tests (under `<subproject>/src/integTest`) to verify changes from a user perspective
- [x] Provide unit tests (under `<subproject>/src/test`) to verify logic
- [X] Update User Guide, DSL Reference, and Javadoc for public-facing changes
- [ ] Ensure that tests pass sanity check: `./gradlew sanityCheck`
- [x] Ensure that tests pass locally: `./gradlew <changed-subproject>:quickTest`
### Reviewing cheatsheet
Before merging the PR, comments starting with
- ❌ ❓**must** be fixed
- 🤔 💅 **should** be fixed
- 💭 **may** be fixed
- 🎉 celebrate happy things
opened 02:43PM - 20 Jul 23 UTC
a:feature
in:plugin-development
### Expected Behavior
Provide a Gradle property that would allow an override fo… r the Gradle library repository that can be committed to gradle.properties
```
org.gradle.libraries.sourceRepository=[internal-maven-url]
```
FWIW I'm willing to open a PR to provide this, more so looking for alignment that the team would accept something like this
We don't want to break anyone depending on the existing environment variable configuration. Introducing a second source for this does raise a question of which one should take precedent when both are present - if there's a norm for this within the project that would be helpful to hear (also poking around for a few examples)
### Current Behavior (optional)
```
export GRADLE_LIBS_REPO_OVERRIDE=[internal-maven-url]
```
### Context
Teams working in tighter security environments may have network traffic to external maven repositories blocked
This has a few negative impacts
- Gradle isn't able to download Groovy resources that it needs/wants
- Erodes developer productivity, during IDE sync we see ~1700 retries fail while attempting to fetch these which can add upwards of ~4 minutes to our IDE sync times
As mentioned in https://github.com/gradle/gradle/issues/24217 these is an existing workaround that resolve this issue
This is great for an individual but hard for teams. In an environment of hundreds or thousands of engineers we'd have to make a large announcement, hope they apply the workaround, etc. This is pretty expensive and results aren't very durable for new people joining a team, machine upgrades, etc
Vampire
October 25, 2024, 7:31am
5
There were even two PRs doing the same. Well, we have to wait for the proper fix then that is hopefully coming in Gradle 9.x, it seems.
