Restriction that plugin versions must be string literals is onerous

Old Forum Archive Bugs
1

Gradle Version: 2.14
Operating System: Irrelevant
Is this a regression? If yes, which version of Gradle do you know it last worked for?

This is not a bug, really, but it is an issue, and not merely a point for discussion, and there’s nowhere else to put such issues… Gradle 2.14 has very strict syntax about what can be placed inside a plugins{} block.In particular the version element of each item is restricted to being a string literal.

In my situation, which I will explain below, this restriction is a show-stopper - enough to prevent usage of the plugins{} block in favor of the older “apply” syntax.

I am developing a collection of plugins for our organization, packaged in a jar. I’d really like to use the pluginRepositories{} feature and the new plugins{} syntax. But my plugins are changing often, and it has been necessary to define the concept of a “stable” version (defined in the environment) which could be def’d in the top level build.gradle of a multi-project and then all users of the plugin collection could choose that version. Whereas developers of the plugin collection (i.e, me) could, with a simple change of the top level build script, walk out onto the bleeding edge.

But with this restricted syntax, it is impossible to define a stable version and refer to it in a build script. So every time a new version of my plugin collection needs to be released, instead of changing a variable in the global environment, every user of that collection must manually edit all the subproject buildscripts of each project using these plugins. You can’t even change a variable at the root level.

Definitely a problem.

2

The main point here is that with the previous system, it was possible to define the version of a plugin collection to be used at the top level of the project and now it is not.

This ability is lost with the very strict syntax that requires both that

  1. such definition must be made at the child project level, not the parent level and furthermore that
  2. it be a literal, precluding the opportunity to define a property at the parent level and use it at the child level

In my situation, this is a significant backward step.

Easing either of these restrictions would be a big help.

Thanks.

3

I’ve responded to the other post you opened about this limitation, let’s take the discussion there.