Testing snapshot deployment of a plugin under construction

Help/Discuss
1

I am just starting out creating a plugin for our build system. My plugin has one task that prints a message. I am able to publish a snapshot of this plugin to our artifactory snapshot folder and my first usage of it from a test build file works. However, subsequent publishing of an updated snapshot of the plugin fails to get pulled into my test build (it is cached). I can bump the revision of the snapshot, publish the new version, and this works (defeats the cache), but that kind of defeats the purpose of the snapshot no? I’ve seen a few posts about defeating the cache of a specific dependency by adding:

configurations.all {
    resolutionStrategy.cacheChangingModulesFor 0, 'seconds'
}

and setting the ‘changing’ attribute on my plugin dependency:

dependencies {
    classpath ('org.my.gradle:my-gradle-plugins:1.0.7-SNAPSHOT') {
        changing = true
    }
}

None of these settings has any effect. The plugin remains cached. I certainly don’t want to blow away the entire cache and bumping the revision works but I’d really prefer not to have to do this while I’m coding the plugin as it is somewhat labor intensive.

Ideas?

2

Gradle recognized a dependency with the version suffix -SNAPSHOT automatically as changing version. Subsequently, marking the dependency as changing is redundant. I personally would go with the resolutionStrategy.cacheChangingModulesFor option. In your code example you are setting this strategy for all configurations available to the project. However, if you are depending on a plugin, declared as buildscript dependency then the configuration classpath is not part of this collection. You’ll have to go with the following option:

buildscript.configurations.classpath {
    resolutionStrategy.cacheChangingModulesFor 0, 'seconds'
}

The important take away here is that the repositories, configurations and dependencies buildscript block are different from the ones declared on the top-level of the build script. You can read more about here. We are planning to provide better documentation in this area as well to get the point across.

1 Like
3

Solved! Made the change to move the resolutionStrategy to the buildscript block, tested plugin updates several times and each time I got the latest published snapshot of the plugin. It makes perfect sense, upon reviewing the solution, that the resolution strategy would belong in the buildscript specific config (classpath). Thanks again for the information.