Error "NoSuchKey" for plugin

Because of some bug under Windows I need to use the recently published version 1.1.1 of the plugin gradle-eclipseconfig. While that plugin is shown on the web page already and one can have a directory listing, it doesn’t resolve in build.gradle. I get the following errors:

Caused by: org.gradle.internal.resolve.ModuleVersionNotFoundException: Could not find org.standardout:gradle-eclipseconfig:1.1.1.
Searched in the following locations:
Required by:
	project > org.standardout.eclipseconfig:org.standardout.eclipseconfig.gradle.plugin:1.1.1

I tried to download the mentioned files manually and got the following XML from the web server:

<?xml version="1.0" encoding="UTF-8"?>
	<Message>The specified key does not exist.</Message>

Has the plugin been published properly or is there some error? Does it still take some time to finish the publishing and I simply need to wait? Might it have something to do with new approval of plugins needed?

The other files of the plugin can easily be downloaded without the formerly quoted XML response. But those are from 2016 already. So if the publishing went wrong for some reason, I would like to notify the maintainer of that plugin to have another look.


This problem makes it unnecessary difficult to use some project in CI like Jenkins, because without the plugin being publicly available, one needs to provide other sources to make it available. I formerly simply used a local fork of the GitHub-repo and while that works locally in Eclipse etc., that repo would need to be made available to Jenkins as well. There’s a simpler workaround, though:

The published version for Maven works and contains everything needed to be used as a plugin. So we can use that in build.gradle like the following:


	id 'eclipse'
	id 'java-library'
	id 'org.standardout.eclipseconfig' version '1.1.1'

buildscript/repositories/jcenter() is the important part, resolving the plugin using Maven. Once the problem of this thread has been resolved, that should become unnecessary, but shouldn’t harm as well.

One thing to additionally note: I’m using eclipseconfig in a project which itself provides a plugin based on eclipseconfig and for some reason all my projects depending on my own plugin need to provide buildscript/repositories/jcenter() as well to properly resolve eclipseconfig in version 1.1.1 like mentioned above. I would have expected such details not leaking into the depending projects, but can live with that for now.

Hi Thorsten,

Bummer, it looks like the plugin artifacts were not properly uploaded/stored. This isn’t related to plugin approval which only affects new plugins (not new versions). We have 2 options to resolve this:

  • You publish 1.1.2 and use that (recommended)
  • I can manually delete 1.1.1 and you can republish

What works for you?


Thanks for looking into this, but I’m not the owner of that plugin. I’ve created an issue upstream linking here, but in the meantime in my opinion it’s best to delete 1.1.1. It’s not usable the way it is currently and only confuses people if it’s shown on the web page etc. At least as long as the publication at Maven is not affected by your deletion, because the plugin works if downloaded from there.