Can plugins{} DSL be used to locate custom plugins packaged in a jar of many plugins?


(Steve Cohen) #1

Continuing the discussion from New Custom Plugin Feature of gradle-2.14 and plugin bundles:

Summary:

I’ve built a custom version of the gradle-os-package plugin collection and repackaged it with a groupId amenable to my corporation’s nexus which I want to use as a private plugin repository as per the new feature in gradle-2.14.

However, I am brought up short by the fact that the old apply plugin syntax still seems to allow more expressive syntax than the new plugins{} DSL. The key graf in the related issue 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]

and refers to this line of build gradle:

plugins {
    id 'nebula.rpm' version '3.4.2'
}

But the plugin identified by nebula.rpm is not contained in a jar called nebula.rpm.gradle.plugin-3.4.2.jar. It is deployed in gradle-ospackage-plugin-3.4.2.jar. Somehow, it seems, the apply plugin syntax (together with an
appropriate buildscript{} block) allows resolution down to the plugin level. But the plugins{} DSL syntax seems to be making an assumption about how the plugin id relates to the jar name under which it is packaged.

Please note that this has nothing to do with with the new plugin repositories feature of gradle-2.14. Since the correct jar cannot be located from the parameters supplied in the plugins{} block it would seem to apply to any collection of plugins packaged into a single jar. Or possibly there is a difference between the Gradle plugins repo and a maven repo being used for this purpose.

Unless I am missing something …


Can plugins{} DSL be used with plugins that have dependencies on other plugins?
(James Justinic) #2

You’re missing something…

The plugins {...} DSL could only use the Gradle Plugin Portal prior to Gradle 2.14 at least partially because there is a REST API at plugins.gradle.org which does the mapping from the plugin ID to the correct coordinates for the artifact. In the case of the nebula.rpm plugin, it contains a mapping to gradle-ospackage-plugin artifact as shown below:

{
  "id" : "nebula.rpm",
  "version" : "3.6.1",
  "implementation" : {
    "gav" : "gradle.plugin.com.netflix.nebula:gradle-ospackage-plugin:3.6.1",
    "repo" : "https://plugins.gradle.org/m2"
  },
  "implementationType" : "M2_JAR",
  "legacy" : true
}

When opening up the plugins {...} DSL to other repositories, it would be unreasonable to require running a separate server alongside the artifact repository to respond with this extra information. Instead, Plugin Markers are published alongside the plugin in the case of a private repository. There was information about this in the 2.14 Release Notes with a link to the User Guide that is also included above.

This does have a lot to do with the new plugins repositories feature of Gradle 2.14 because the plugins {...} DSL requires the marker interface if the repository is not the Gradle Plugin Portal. You will need the marker interface published in your corporation’s Nexus for what you want to do to work. The error you’re receiving is at the coordinates of where the marker interface should be located. The normal mechanisms are falling back to JAR when the POM is not there.


(Pepper Lebeck-Jobe) #3

@jjustinic is totally right in diagnosing the problem. As you mentioned in your original post, if you are publishing the plugins with a version prior to 2.14, and then trying to use those published plugins from 2.14, you’ll also have to manually push a Plugin Marker Artifact. That’s basically, just a POM or Ivy file with a single dependency on the actual implementation artifact.


(Steve Cohen) #4

Thanks. That was what I was missing. If publishing plugin with < 2.14, then the Plugin Marker Artifact does not get generated!