Version Management of Plugins Under Development


(Steve Cohen) #1

I am developing a group of plugins that will be used on our team.

I elected to use the “standalone project” approach (section 39.5 of user’s guide).

The buildSrc/build.gradle of each project using the plugin specified the plugin id and version number. Every build I made of the plugin pushed the latest version of the plugin jar to the local maven repo. The test projects picked it up from there.

For a blissful while, while I was the only one using my plugin, I could experiment to my heart’s content. I never had to change the version number. Once this was rolled out to my team, that had to change. Some of my intermediate changes broke builds, and this would not do. So I would bump the version of the plugin when I had to make changes, play with it to my heart’s content, without disturbing the stable version in the Maven repo. I would then send emails saying that a new version had been “released” and developers should update their buildSrc/build.gradle to specify it.

It didn’t take long for someone to ask for a way to specify the use of the latest version of the plugin instead of a version number. I understand the convenience of this, but of course, it would defeat the purpose of my bumping the version number for my own use until I was ready to publish that the new version was ready.

So what I’m looking for is a way of specifying that, say 1.0.2 is the latest stable version of my plugin and have that property generally available to any of the users of my plugin, to be used in their projects’ buildSrc/build.gradle.

Are there other strategies for handling this situation of a plugin in general use while it is still being enhanced?


(Steve Cohen) #2

never mind. found https://docs.gradle.org/current/userguide/init_scripts.html


(Steve Cohen) #3

Well actually, this document teases me with the possibility of a solution without actually providing an example of what I need. In Section 42.1 it says

Set up properties based on the current environment, such as a developer’s machine vs. a
continuous integration server.

Okay, I thought I might set up a property called myPluginLatestStableVersion.

But how to define such a property in the init script?

In Section 16.4 of User’s Guide we have:

There are two kinds of variables that can be declared in a build script: local variables and extra properties.

Well, it’s not a local variable, so maybe an extra property.

ext {
        myPluginLatestStableVersion = "1.0.2"
}

But now, when I go to reference this property in a build script, I get errors.
whether I do
println myPluginLatestStableVersion
or
println ext.myPluginLatestStableVersion
or
println project.ext.myPluginLatestStableVersion

I get a missing property exception.

If there was a way to put a PROPERTIES file in the $GRADLE_HOME/init.d directory that would probably work, but how can I make the properties defined in the init.d BUILD SCRIPT accessible in my build scripts?

I’m sure there must be a way to define such a property but I’m not finding it.


(Steve Cohen) #4

Well, here is one solution:

$GRADLE_HOME/init.d/init.gradle:
System.setProperty("org.gradle.project.myPluginLatestStableVersion", "1.0.2");

build.gradle:
println myPluginLatestStableVersion

prints
1.0.2

I still think there ought to be an easier way.