Is there a way to proxy the gradle plugin portal through local artifact repository?

Old Forum
1

The new way of configuring plugins looks nice, and the portal is convenient for finding things, but I am not clear how is it supposed to work in your typical enterprise.

In this kind of environments, the local artifact managers (Nexus, Artifactory) are used as a point of audit and setting a direct connection through a HTTP proxy will likely trigger all kinds of compliance alerts.

1 Like
2

There’s no proxying capability yet, other than generic HTTP proxying and whilte/black listing.

It’s something we are keenly aware of, it’s just not there yet.

You can still use all the plugins in the portal the old way in the meantime. At this level of usage, the portal just becomes a search interface.

3

Thanks, good to know that it is on the roadmap.

4

This is super-critical feature for us. Without it I can’t start migrating our Maven builds. Also an idiomatic way of externalizing all URL references in Gradle builds (like repository configs in settings.xml) is a must. Any info on priority and timing would help the planning efforts.

Regards,

Ron

1 Like
5

The plugin portal pulls binaries from Bintray’s JCenter, which is just a HTTP Maven repository (which can easily be locally proxied). The plugin id to implementation resolution can’t be. However, you don’t have to use that to use Gradle plugins. You can use the older plugin use mechanism which will work with a proxied repo just fine.

I wouldn’t let this stop you migrating.


6

I’m not familiar with the “older” mechanism. Is there link you can share?

7

The older way is ‘apply plugin: “foo”’. For third-party plugins, you’ll additionally need a ‘buildscript’ block to pull them in. http://plugins.gradle.org shows how it’s done under “Build script snippet for use in all Gradle versions”.