Is the {plugins} section ready for prime time?

Help/Discuss
1

I am cautiously eyeing the “Publication and consumption of plugins to and from custom repositories” from Gradle 2.14 release notes, yet before I start kicking the tires, I would like to ask:

  • the 2.14 release notes mention that the gradle-plugin automatically adds the plugin marker artifact is to ivy/maven-publish tasks. How about artifactoryPublish?
  • Can we apply the new plugin repo config from init script? Which hook shall we use? Do you have example by any chance?
  • Is there still a restriction that we can not use plugins section within allprojects/subprojects?
  • I know that the plugins section supports a restricted subset of the Groovy syntax - does it allow to use project properties to define plugin versions?
  • What would be the programmatic way to apply plugins resolved by the new mechanism? I.e. if I want to apply a plugin from another plugin.

Even if some of these are not supported yet, I am interested with their relative priority in the roadmap.

1 Like
2

Hi Dimitar,

those are some excellent questions!

  1. I don’t know much about the artifactory plugin. The java-gradle-plugin automatically adds publications for the plugin markers. As long as the artifactory plugin honors those publications, you should be good to go.
  2. Defining plugin repositories from an init script is not yet implemented, but definitely something we will do in the future. This is pretty high on the list of priorities for the plugin DSL, probably only trumped by dynamic versions.
  3. As of Gradle 3.0, you can resolve plugins using the new DSL without applying them to the current project (using the apply false option). You can then use the existing apply plugin: syntax to apply it to whatever subproject you want.
  4. Only literal Strings are supported. Can you tell me more about the use case for using a property?
  5. You want to apply a plugin from another plugin. So I assume you mean a binary plugin that you build as a standalone project. Since that project already has a dependency on that other plugin, you can use the existing apply plugin: method to apply that other plugin inside your plugin’s apply() method.

Cheers,
Stefan

3

Thanks Stefan!

  1. Artifactory wouldn’t publish these automatically, but our enterprise conventions plugin will take care of this, so we are all good.
  2. That is a must for us - we don’t want this kind of information in the checked in files. It belongs in the build-environment that is versioned separately.
  3. Good, so the old apply plugin: 'xxx' is not deprecated? That also takes care of #5.
  4. We would like to be able to externalize some versions, so all plugins from a suite can share the same version.
    Also it is often useful to have them overridable in user properties and command line.
    Let me know if you think that is a bad idea or there is another way to achieve the same.
4

Thanks for the detailed feedback and use cases. We are currently planning the next iteration of the plugins DSL and taking your feedback into account for that.