Feature Request - specify plugin version other than by String Literals


(Steve Cohen) #1

I must preface this by stating that I haven’t actually tried 3.0 M2 or any version of 3.0 yet. My comments are based totally on the release notes.

I wish to ask for consideration to be given in 3.0 to my use case, which is expressed in this “bug” report.

My use case involves multiproject builds made up of subprojects each of which extends a plugin that is packaged in a plugin collection that I have written which is still undergoing constant development, even as it is being used to build other projects, that are our team’s bread and butter.

Because of the String Literal restriction, it is much more difficult to upgrade to the latest version of the plugin collection. The old buildscript{} syntax made this relatively easy. With the new syntax, if we adopt it, this task becomes something of a nightmare. At the very least the version of the plugin to apply should be settable from an environment variable or a system property, so that updating this does not require editing multiple subproject build scripts.

Thanks for considering this.


(Eric Wendelin) #2

Thanks, Steve, for raising your concerns.

We are designing the future of plugins {} and we are including this feedback in our discussion.

Members of that team will follow up once there are updates here.

Cheers,
Eric


(Stefan Oehme) #3

Hi Steve,

we are considering to allow access of simple properties in the plugins block, so you could access what you have defined in gradle.properties for instance. Would that work for you?

Cheers,
Stefan


New Custom Plugin Feature of gradle-2.14 and plugin bundles
(Steve Cohen) #4

Hi, Stefan. Well, it depends on how simple. I don’t think that a property definable only in gradle.properties helps that much. I probably would NOT want it to be the same for all projects. And if not, I’d still have to redefine it in multiple subprojects. I’d want to be able to redefine it elsewhere - on the command line at bare minimum, and hopefully in some block of logic at the rootProject level, at the top of build.gradle, say. This logic might want to look for environment variables, say.

Basically, i’d like the level of flexibility I have with the old system or with as little restriction of that as possible.


(Steve Cohen) #5

A cursory glance at the Release Notes and new User’s Guide for 3.0 indicates that nothing was done on this issue - hardcoded string literals for plugin versions are still required. This remains a big stumbling block in my use case of a developing collection of local plugins (14 versions since we’ve begun using Gradle earlier this year, over a wider and wider array or projects). With 2.x, I change one environment variable and all projects can use the latest stable version without any script changes (and can also opt out of this system by using hardcoded versions if need be).

So this remains a step backward in my situation and prevents a port to 3.x.


(Stefan Oehme) #6

Why would it prevent moving to 3.x? The old plugin mechanism is still supported.


(Steve Cohen) #7

You’re right and I misspoke. It would prevent moving to the new plugin mechanism, though.