Uploading snapshot versions to the plugin portal


(Ned Twigg) #1

Is it possible to overwrite snapshot versions in the plugin portal?

The first upload of 1.3.0-SNAPSHOT went fine:
https://plugins.gradle.org/plugin/com.diffplug.gradle.spotless

But when I tried to upload a second rev of 1.3.0-SNAPSHOT, I got this error:

Execution failed for task ‘:publishPlugins’.
Failed to post to server.
Server responded with:
Plugin: ‘com.diffplug.gradle.spotless’, version: ‘1.3.0-SNAPSHOT’ exists already. It was created: 2015-04-30 22:04:23.151

https://travis-ci.org/diffplug/spotless/builds/77340082

Is there a property I need to set in com.gradle.plugin-publish to overwrite with the latest snapshot?


(Kon Soulianidis) #2

Hi Ned

Thanks for your enquiry. We dont support snapshot versions at this stage.

Kind regards

Kon

Ned Twigg wrote:


(Ned Twigg) #3

Understood. I’m a big fan of Gradle, and you guys are doing great work! I think the idea of the plugin portal is fantastic, and you guys did a great job with what seems to me like the hard part - API keys, delivering the plugins, a nice search feature for discovering new plugins, etc.

Supporting snapshot versions seems easy compared to this, and the whole idea of the portal and the new plugin syntax is tanked if we can’t publish snapshots. If we can’t publish snapshot versions, then we can’t actually use plugins.gradle.org for development - we have to stage them somewhere else while we’re doing testing. If we have to stage somewhere else, then anyone who wants to help test cutting edge versions can’t use the nice

plugins {
    id "com.some.plugin" version "0.4.1-SNAPSHOT"
}

syntax, which really undercuts adoption of the portal and the syntax. It also makes it much harder to get people to test new versions of our plugins - if they have to add some one-off URL to their maven repo lookup, it’s a much higher bar than just bumping their version number.

There are other seemingly simple bugs in the portal which have gone a long time without fixing. I know you guys have a full plate, but every day this goes unfixed is another day that active plugin developers have to use the old syntax and third-party repository hosting options in order to contribute to the plugin ecosystem.


(Kon Soulianidis) #4

Hi Ned

Appreciate you taking the time to let us know how you use the portal and what can be improved.

Since releasing the plugin portal plugin we’ve come to appreciate the different workflows for publishing plugins. Whilst we aren’t in a position to support snapshot releases today we’ll take the feedback onboard.

In the meantime, taking a look at your plugin source, I did like the workaround in your build so as not to publish snapshot versions with the plugin-publish plugin. I was going to suggest that if you wanted to upload a version to the plugin portal when in SNAPSHOT mode, you could look at changing the -SNAPSHOT of the version to using a timestamp suffix. This would allow you to share versions and get feedback about particular versions as well.

Thanks for your understanding with this. I should mention that we are hiring too, so if you or anyone you know is interested in helping make Gradle better, please send them the way of the link.

Best

Kon


(Ned Twigg) #5

Thanks for this feedback Kon, and I hope you have good luck in recruitment.

Deploying based on timestamp or commit sha is a good idea, but I fear it would be expensive for you in the long run. My plugin is 8MB (it uses a fat jar approach to get around some limitations), and it has ~100 commits so far. If I had been using this policy, I would have deployed around a full gigabyte to your servers by now. I guess storage is cheap these days, so that’s probably not a big deal, but it is 30x more storage for you than if the portal supported snapshot versions.


(RickH) #6

There are really two issues here in terms of different workflows. Yes, there’s the difference in publishing plugins, which requires different configurations and conditionals so that snapshots aren’t pushed to the plugin portal.

But this also requires two different workflows for projects that use the plugin as a dependency, one for using release versions and one for using the plugin portal version. And not only does it require two different workflows, it requires two separate build.gradle files, since you can’t do something like this:

// For plugin portal
plugins {
    id "org.foo.bar" version "1.0"
}

buildscript {
    repositories {
        mavenLocal()
        maven { url 'http://snapshot.repo.com' }
    }
    dependencies {
        classpath "org.foo:bar-plugin:1.0-SNAPSHOT"
    }
}

apply plugin: 'foobar'

These are incompatible and there’s no way to conditionalize the plugins block, since that has to be the first element in the configuration.

Basically the formats of the different ways of including plugins are different enough that not supporting development workflows through the portal basically means using the portal will remain an afterthought to developers. I mean, I was psyched to use it, immediately ran into this problem, and am now reverting all my changes and probably won’t look at it again.

On a related note, my snapshot version plugin was installed easily enough on the portal, but when I try to reference it in my build.gradle, I get a message that “snapshot plugin versions are not supported”. That’s fine (well, it’s not but it’s understandable), but the portal should probably block snapshot versions from even being published if that’s the case.


How does `pluginRepositories` handle SNAPSHOT versions?
(steve) #7

It would be nice if the plugin publishing plugin at least gave some indication that this is not supported, rather than blindly accepting the upload:

https://plugins.gradle.org/plugin/org.hibernate.build.testing.databaseprofile


(Eric Wendelin) #8

@marcphilipp I think you would be interested in Steve’s feedback here as we consider a new plugin publishing plugin.