‘gradle-core’ depends on a class in ‘gradle-base-services-groovy’ (‘org.gradle.api.specs.AndSpec’), but this artifact is not available from http://repo.gradle.org or listed as a dependency of ‘gradle-core’ (for Gradle 1.6).
How are you affected by this?
It’s probably a somewhat odd situation, but I using Maven to develop a Gradle plugin.
We’re migrating our end-user tooling to be a plugin (and front-end if necessary) for Gradle rather than an ad-hoc collection of our own stuff, but the project itself is built with Maven and we don’t particularly want to rewrite its build system right now. So I am trying to use Maven to fetch the necessary dependencies to write a Gradle plugin, and the absence of gradle-base-services-groovy means that Maven cannot compile my Gradle plugin.
I have worked around this issue by putting a repackaged Gradle JAR in my local Maven repository, but this issue may affect publishing to Central.
The current expectation is that Gradle plugins are built with Gradle, and that their POMs don’t declare any Gradle dependencies. (Gradle is effectively a ‘provided’ dependency). As far as I understand, the goal is to publish the wrapper and tooling API to repo.gradle.org, not necessarily the plugin API.
Nevertheless, thanks for the pointer that ‘gradle-base-services-groovy’ isn’t published to repo.gradle.org. This may be an oversight, and I’ll take it back to the team.
That is an understandable expectation — trying to build a plugin for a build system with a different build system is, admittedly, a somewhat strange goal.
Actually, we use Gradle to build plugins and have the same problem.
Previously, my build logic would inject the jars of the gradle-running-the-scripts into the classpath.
But I’m working on migration from 1.0-milestone-3 to 1.6, so I need to compile the plugins against another Gradle version than the one running the build. And so I use the repository-provided artifacts as provided dependencies.
I guess I’ll have to hack it a bit, and force-feed it the gradle-base-services-groovy jar.