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.
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.
Thanks, good to know that it is on the roadmap.
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
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.
Iâm not familiar with the âolderâ mechanism. Is there link you can share?
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â.