No info for 401 while requesting private maven repo

Help/Discuss
1

We use a private maven repository hosted on Azure. We added it to our settings.gradle.kts. The tokens we use as password have a limited lifetime.

Everything is working fine. But as soon as a token is outdated, we simply get an generic build error:

FAILURE: Build failed with an exception.

* Where:
Build file '/Users/user/app/build.gradle.kts' line: 1

* What went wrong:
Plugin [id: 'com.ourcompany.someplugin', version: '1.0.0', apply: false] was not found in any of the following sources:

- Gradle Core Plugins (plugin is not in 'org.gradle' namespace)
- Included Builds (None of the included builds contain this plugin)
- Plugin Repositories (could not resolve plugin artifact 'com.ourcompany.myplugin:com.ourcompany.myplugin.gradle.plugin:1.0.0')
  Searched in the following repositories:
    MavenRepo
    Gradle Central Plugin Repository
    OurCompany(https://pkgs.dev.azure.com/ourcompany/_packaging/ourcompany/maven/v1)

If I run any task with --debug I can see:

[INFO] [org.gradle.internal.resource.transport.http.HttpClientHelper] Failed to get resource: HEAD. [HTTP HTTP/1.1 401 Unauthorized: https://pkgs.dev.azure.com/ourcompany/_packaging/ourcompany/maven/v1/com/ourcompany/myplugin/com.ourcompany.myplugin.gradle.plugin/1.0.0/com.ourcompany.myplugin.gradle.plugin-1.0.0.pom)]

Is there any way to tell the user, that there was an auth issue with the used credentials?

Edit: We are using Gradle 8.13.

2

I’d say that is a bug in the resolution of plugins.
Specifically this one: Lack of diagnositcs in resolving of plugins · Issue #15424 · gradle/gradle · GitHub.
For normal dependency resolution you get the expected error as soon as a repository returns anything >= 400 that is not 404.

As a work-around you could somewhere add "com.ourcompany.someplugin:com.ourcompany.someplugin.gradle.plugin:1.0.0" as a normal dependency, for example in buildSrc if you have it, or as settings script dependency using

buildscript {
    dependencies {
        classpath("com.ourcompany.someplugin:com.ourcompany.someplugin.gradle.plugin:1.0.0")
    }
}

or similar, as those would properly fail because of the 401.

Actually, as you anyway had apply false, you can also in the build script remove the plugin line and put the buildscript snippet there as work-around, it will then have the same effect of putting the plugin to the buildscript classpath but properly failing.

3

@Vampire Thank you very much! I search for this topic, also in the Github issues but somehow did not came across: Lack of diagnositcs in resolving of plugins · Issue #15424 · gradle/gradle · GitHub

I tried to add the suggested snipped at the top of our build.gradle.kts. Unfortunately Gradle tries to first resolve the plugins and afterwards shows the same error I initially posted but in line 7 e.g.

Since we have multiple plugins hosted on our private repo and some need to be applied to the root project, we can not use this “workaround”. :frowning:

Maybe the linked issue will be fixed someday.

4

I tried to add the suggested snipped at the top of our build.gradle.kts . Unfortunately Gradle tries to first resolve the plugins and afterwards shows the same error I initially posted but in line 7 e.g.

Yes, of course.
You only did half of what I said.
I said to have it in the build script you need to remove the plugin line.

Since we have multiple plugins hosted on our private repo […], we can not use this “workaround”.

What has one to do with the other?
Just add them all if they are in multiple code artifacts, if they are in the same, then depending on one already adds all.

and some need to be applied to the root project

Well, you didn’t say that before, but you still have options like I described here and also further options in said ticket.
For example you can instead add to a parent class loader like buildSrc dependency or settings script classpath class loader if there are no other hindering options like described.
Or you can anytime use the legacy application as also described in said ticket and live with not having type-safe accessors for those plugins in the root project build script.