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
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.
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:
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.
@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.