How does `pluginRepositories` handle SNAPSHOT versions?

Help/Discuss
3

Understood. I’ve always felt this default was decidedly backwards. In case there’s any chance of a change in 3.0, here’s a pitch:

               | Cache by default                 | Don't cache by default          |
---------------+----------------------------------+---------------------------------+
Build time     | Instantaneous after first load   | +100ms to check for stale POM   |
---------------+----------------------------------+---------------------------------+
Developer time | Anytime someone tests a SNAPSHOT | +100ms per build so long as     | 
               | and has a problem, you have to   | the dev is testing a SNAPSHOT.  |
               | ask "is it old?" and describe    |                                 |
               | the various workarounds.         |                                 |
---------------+----------------------------------+---------------------------------+
Difficulty of  | To disable caching, add 5 lines  | What is the usecase for wanting |
switching to   | to buildscript, using concepts   | a stale SNAPSHOT?  Whose        |
other behavior | that users wouldn't otherwise    | bandwidth is too expensive to   |
               | ever have to know about.         | check for a stale POM?          |
---------------+----------------------------------+---------------------------------+

Also, I feel like you guys have built all the hard parts of this fantastic plugin system, but you keep getting the plugin workflow wrong in a fundamental way. Here’s a user story that’s been broken since the beginning of the plugins{} block, and is still broken with the introduction of the pluginRepositories{} block.

I maintain a Gradle plugin, and my users ask me for an improvement / bugfix. I publish a SNAPSHOT, and they want to test it.

First off - I can’t upload SNAPSHOTs to the plugin portal, so I have to make sure they add the OSS snapshots repo to their buildscript. Which now they can, hooray!! Not quite as good as if the portal handled SNAPSHOTs, but at least we can now use the plugins{} block.

pluginRepositories {
    maven {
        url 'https://oss.sonatype.org/content/repositories/snapshots/'
    }
}

They test it, and find a problem. I fix it, and publish a second SNAPSHOT. But they say it’s still broken. So now we spend some cycles making sure they add this:

pluginRepositories {
    maven {
        url 'https://oss.sonatype.org/content/repositories/snapshots/'
    }
}
buildscript {
    configurations.all {
        resolutionStrategy.cacheChangingModulesFor 0, 'seconds'
    }
}

And even that might be wrong because maybe the buildscript block has to go first? I don’t know. That’s TEN lines of boilerplate that has to go on the top of every single buildscript before users can be an active, SNAPSHOT-testing member of the community. 5 lines are because the portal doesn’t support SNAPSHOTs, and the other 5 are because the default is backwards.

There’s a couple minor problems stacked on top of each other that make the overall process quite hairy, and make it impossible to take advantage of your otherwise beautiful design. But maybe I’m missing a shortcut?

1 Like