OK, I have gotten halfway down this path. I have packaged redline and gradle-os-plugin with a groupId acceptable to our corporate nexus rules and deployed them there.
Now onto the task of trying to adopt this new syntax, which would indeed be helpful. But here I hit a roadblock:
* What went wrong:
Plugin [id: 'nebula.rpm', version: '3.4.2'] was not found in any of the following sources:
- Gradle Core Plugins (plugin is not in 'org.gradle' namespace)
- maven({our corporate repo url}) (Could not resolve plugin artifact 'nebula.rpm:nebula.rpm.gradle.plugin:3.4.2')
- Gradle Central Plugin Repository (plugin 'nebula.rpm' has no version '3.4.2' - see https://plugins.gradle.org/plugin/nebula.rpm for available versions)
I would only expect the second source to resolve. It contains our private version of gradle.ospackage.plugin, v 3.4.2 which provides the nebula.rpm plugin. But it fails. And so our custom plugin cannot build this way.
I also was intrigued by the error message that it was nebula.rpm:nebula.rpm.gradle.plugin:3.4.2 which could not be resolved. That seemed to indicate that it was looking for a plugin named nebula.rpm in a gradle plugin package called nebula.rpm v3.4.2, rather than in gradle-ospackage-plugin v3.4.2 , which is where it actually lives. So I tried specifying it in my plugin block as
id 'nebula.rpm:gradle-ospackage-plugin' version '3.4.2'
rather than as
id 'nebula.rpm' version '3.4.2'
but the former is not legal syntax.
A look at the debug output shows that what the resolution process is searching for is:
10:55:31.833 [INFO] [org.gradle.internal.resource.transport.http.HttpClientHelper] Resource missing. [HTTP HEAD: {plugin repo url}/nebula/rpm/nebula.rpm.gradle.plugin/3.4.2/nebula.rpm.gradle.plugin-3.4.2.jar]
This is definitely wrong.
My suspicion had been that this might have something to do with the fact that gradle.ospackage.plugin is built with a gradle 2.10 wrapper so does not support the new plugin marker syntax. I had been hoping to minimize the changes I would have to do with gradle.os.package plugin (i.e. not use the new gradle 2.14 plugin repository concept there) as this is a temporary workaround.
But now I have to wonder about that. If gradle cannot find the jar containing the plugin, then the contents of that jar cannot be relevant.
Can the plugins block notation even be used to find a plugin that is located in a jar that contains many plugins?