@krulls I’ll be creating a Jira ticket now that we think we know what the problem is. I’ll link it back to this forum post.
Hi guys, a quick update on this situation: I have released a new version of the Plugin Portal that now returns a 200 status on the https://plugins.gradle.org/m2 endpoint.
I’ve tested this with both Nexus and Artifactory with the following observations:
- Nexus: when adding the repository, choose the Proxy Repository option. On setup under the Remote Repository Access section: add the repo URL, set Download Remote Indexes to false, Auto Blocking Enabled to false and File Content Validation to true. The health checks now no longer fail and the repo works as expected.
- Artifactory: when adding the repository as new Remote Repository, select as type Maven. Enter the URL (hitting Test will still render a popup with Connection failed: Error 404: Not Found). However when you choose to Save and Finish, the repository will appear and function as expected.
It is worth noting that our repository acts as a proxy so can not be viewed as a static file structure. Nexus and Artifactory can now cache artifacts on demand as they are fetched via our repository.
Hope this helps!
1 Like
This change definitely improved usability, but only on Nexus.
These settings also worked prior to your change your change, but turning off Auto Blocking was absolutely required for the repository to function. However, after your change, Auto Blocking can be enabled, if desired, with the https://plugins.gradle.org/m2 endpoint now that it returns 200.
No difference with Artifactory. It still works as before, but the test button also still fails. This is because Artifactory always adds the trailing slash when making the test request. The endpoint https://plugins.gradle.org/m2 returns 200, but the endpoint https://plugins.gradle.org/m2/ still returns 404.
If you can return the same response for /m2/ as /m2, this should resolve the usability issue with Artifactory.
Thanks for confirming this. Prior to that release, you would have seen Nexus working but would see a lot of noise in the logs due the endpoint returning 404s. This is now no longer the case.
I have subsequently done another release that also lets the https://plugins.gradle.org/m2/ return a 200 status. I’ve also tested this with both Artifactory and Nexus, and all traces of 404 are now gone.
Let me know if this solves your problem!
Hi,
I tried from our Artifactory and the test button now returns “OK”.
But I still get a strange response when I try to have an artifact resolved:
{
errors: [
{
status: 404,
message: "gradle.org-m2: Error in getting information for 'org/sonarsource/scanner/gradle/sonarqube-gradle-plugin/2.1-rc3/sonarqube-gradle-plugin-2.1-rc3.jar' (Failed retrieving resource from https://plugins.gradle.org/m2/org/sonarsource/scanner/gradle/sonarqube-gradle-plugin/2.1-rc3/sonarqube-gradle-plugin-2.1-rc3.jar: No credentials found for host https://gradleware-plugins.s3.amazonaws.com)."
}
]
}
I am trying to fetch the latest version of the sonar plugin (as previous versions are not working well with Gradle 3.0). See https://plugins.gradle.org/plugin/org.sonarqube for details on the plugin.
“gradle.org-m2” is the name OPS decided to give to the remote repository in Artifactory. So it probably has nothing to do with you guys.
The URL given “https://plugins.gradle.org/m2/org/sonarsource/scanner/gradle/sonarqube-gradle-plugin/2.1-rc3/sonarqube-gradle-plugin-2.1-rc3.jar” works and is providing the JAR when I try to access it via the browser.
I found this error when I tried to access the resource Gradle said it could not find in Artifactory via my browser.
Is this something anybody else sees in their setup or is this a problem with the setup we of our Artifactoy instance?
1 Like
I just tested this locally and it worked for me. Here is how I went about it:
Start Artifactory locally using Docker:
docker run --rm --name artifactory -p 8081:8081 docker.bintray.io/jfrog/artifactory-oss:latest
Add the plugin portal as a Remote Repository pointing to https://plugins.gradle.org/m2/.
Try it with curl:
$ curl http://localhost:8081/artifactory/list/gradle-plugins/org/sonarsource/scanner/gradle/sonarqube-gradle-plugin/2.1-rc3/sonarqube-gradle-plugin-2.1-rc3.jar > plugin.jar
$ jar tvf plugin.jar
Try it in a build:
buildscript {
repositories {
maven {
url "http://localhost:8081/artifactory/list/gradle-plugins/"
}
}
dependencies {
classpath "org.sonarsource.scanner.gradle:sonarqube-gradle-plugin:2.1-rc3"
}
}
apply plugin: "org.sonarqube"
When running gradle tasks I see it pulling down the plugin via my Artifactory instance.
Hope this helps!
A final note that I wanted to leave here was regarding the use of the old vs new way of configuring plugins in your build when mirroring the Plugin Portal using Artifactory or Nexus.
The method of proxying the Plugin Portal that I demonstrated in my previous post using the buildscript block is the old way of configuring plugins. The new way uses the plugins { ... } DSL in the build.gradle file.
The new way also provides a method of setting up a custom plugin repository using a pluginRepositories { ... } block in the settings.gradle file. Unfortunately it does not work with a mirrored plugin repository to date.
However, this will allow setting up of internal repositories where plugins may published and consumed using the new plugin DSL. More details of this can be found at the links above.
Although it is not possible to use the new DSL with a mirrored Plugin Repository yet, some work is planned for the future to enable this.
Is there any update on this mirroring effort? Currently without being able to only down plugins from only our internal mirror we are blocked from utilizing the ‘new way’. Yet increasingly, some plugins are quite difficult to locate without having access to the gradle plugins portal.
Is there something we can watch to track the progress of the work to enable mirrored plugin repositories using the new plugins {...} method?