I am also having this exact issue. This is currently preventing us from migrating to the new version of the Sonar Runner plugin as we have no way of mirroring the Gradle Plugins repo via our local Nexus server
The plugin portal actually serves up an amalgam of three different things:
plugins published to the current portal, which are served up by S3 as you have observed
plugins published in the “old” way to Bintray and served up by JCenter
plugin dependencies which are served by JCenter
Due to the way that plugin resolution works for the plugins { } block in Gradle, Gradle expects plugins and their dependencies to be resolved from the same repo when using that construct. That’s why you see some requests redirecting to S3 and some to JCenter.
This does make automatic mirroring difficult as we can’t currently serve up a file list that spans all three sources of artifacts.
The best suggestion that I can offer right now is manually mirroring the jars / pom files you need for specific plugins that you use into a local repo.
I’m also behind a firewall that prevents Gradle from fetching artifacts from external repositories. It is rather cumbersome to manually mirror the needed plugins (and keeping them updated).
It is unfortunate that the “new and easy way” of plugins is harder to use than the old way, due to the firewall.
Are there any plans to make this easier?
I’m in the same boat. Having a legit maven repository that can be added to our Company’s artifactory pro as a proxy would be ideal. It makes it frustratingly difficult to get work done
you still can mirror https://plugins.gradle.org/m2/ in your artifactory at the moment right? We’re currently working on making the default repository for plugins configurable and you can expect something in one of the next gradle releases.
What do you mean by the “url should work though”, is there any other settings/url we can try out?
In the worst case scenario, I might need to upload those plugins artifact to our local internal repository temporarily. Would you recommend that? is there any other options?
not yet found a valid setup for me, but I’m sure I’m on the right way
Update: what seems to be a bit strange to me (or I did anything wrong): pluginRepositories {} was accepted silently in gradle 2.10 but has no effect but was declined in gradle 2.14.1-rc-1 ?!?!
Please get the M2 Repo working again. Without it there is no way to get plugins behind a firewall.
If you cannot: Please provide another way to fetch the plugins from behind a firewall.
I do not think it is OK that this problem is now ignored for month. It makes using Gradle in an enterprise environment quite hard.
@krulls@Endron I’d like to better understand the problem that you are experiencing, as to my knowledge the M2 Repo has been working all along. It acts as a proxy to S3, or JCenter as @tomd described in an earlier post.
If you try hitting the URL directly on the /m2 resource as above, you will get a 404. However, if you try hitting it with a valid URL such as https://plugins.gradle.org/m2/org/apache/httpcomponents/httpcore/4.1, you will be redirected to an appropriate resource (in this case Bintray).
Could it be that the 404 on /m2 is causing Nexus to break?
@vermeulen_mp I am sorry. Reading my post now I realize I was kind of more angry then was actually needed.
I was under the wrong assumption that the M2 repository just does not work but the link you provided clearly showes that it does.
To the details: We are trying to proxy the Maven repo using Artifactory. But resolution of new artifact versions is not working. When I click the “Test” button in my Artifactory repository configuration screen I get an 404 error showing up. I am not sure if this then causes Artifactory to mark the whole thing as offline. (This is not clear from the documentation https://www.jfrog.com/confluence/display/RTF/Remote+Repositories .)
What is clear that our configuration in Artifactory worked at some point. We have sonarqube plugin 1.2 in there so it looks to me it worked at some point. But when I tried to update to 2.0 the artifact could not be resolved.
@Endron no problem at all, I would love to help you get this sorted as soon as possible. I’m sure that many are struggling with this same issue.
My guess is that usually proxies like this are simply a transparent proxy (like an nginx instance) which would mean that it would respond with something like jcenter does when the root context is requested.
What makes our endpoint different is that it is an intelligent proxy. Although I would not be able to give a listing, I would be able to return a 200 status when you hit our /m2 endpoint.
I think we should do this as a first call, then re-evalute to see if this solves your problem. I’ll post here when this has been implemented.
I agree to @vermeulen_mp that sending a valid return code could be the missing peace in this. I can check with a Nexus 2 and Nexus 3 instance when this has been realized.
@@vermeulen_mp: I am missing links to an issue in an issue tracker to follow the workflow. Don’t you use one? Or is it private? Is there any other way than waiting for a new reply to this post to track the progress?
Adding a page that returns a status code of 200 will alleviate much of the confusion that has been expressed on the forums about proxying the Gradle Plugins repository. Most users expect that they can just create a proxied repository with the default settings, see success messages, and be on their way.
Nexus has required non-default settings since the plugin portal was created in order for it to work. It doesn’t work unless you know to change the default settings (due to the 404).
Artifactory gives you the sense that it doesn’t work because hitting to test button shows an error (also due to the 404). I’ve not seen any Artifactory issue that wasn’t actually caused by some other underlying issue, but getting a good test result would help speed up investigation.
