[GRADLE-2805] gradle-base-services-groovy not published to repo or in dependency tree Created: 22/Jun/13  Updated: 24/Jan/17  Resolved: 24/Jan/17

Status: Resolved
Project: Gradle
Affects Version/s: None
Fix Version/s: None

Type: Bug
Reporter: Gradle Forums Assignee: Unassigned
Resolution: Duplicate Votes: 2


`gradle-core` depends on a class in `gradle-base-services-groovy` (`org.gradle.api.specs.AndSpec`), but this artifact is not available from [1]http://repo.gradle.org or listed as a dependency of `gradle-core` (for Gradle 1.6).
[1] http://repo.gradle.org

Comment by Gradle Forums [ 22/Jun/13 ]

How are you affected by this?

Comment by Gradle Forums [ 22/Jun/13 ]

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.

Comment by Gradle Forums [ 22/Jun/13 ]

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]([1]http://forums.gradle.org/gradle/topic...).
[1] http://forums.gradle.org/gradle/topics/publish_source_and_javadoc_jars_for_gradle_to_maven_central

Comment by Gradle Forums [ 22/Jun/13 ]

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.

Comment by Gradle Forums [ 22/Jun/13 ]

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.

Comment by Axel Fontaine [ 10/Jul/13 ]

I am also affected by this. And no, building Gradle plugins with Maven is not uncommon. Any project with support for multiple tool plugins will at some point face this dilemma: stay with a single build tool or fork, run a second one, and reattach the artifacts. For me the first option is definitely the easiest.

Comment by Benjamin Muschko [ 15/Nov/16 ]

As announced on the Gradle blog we are planning to completely migrate issues from JIRA to GitHub.

We intend to prioritize issues that are actionable and impactful while working more closely with the community. Many of our JIRA issues are inactionable or irrelevant. We would like to request your help to ensure we can appropriately prioritize JIRA issues you’ve contributed to.

Please confirm that you still advocate for your JIRA issue before December 10th, 2016 by:

  • Checking that your issues contain requisite context, impact, behaviors, and examples as described in our published guidelines.
  • Leave a comment on the JIRA issue or open a new GitHub issue confirming that the above is complete.

We look forward to collaborating with you more closely on GitHub. Thank you for your contribution to Gradle!

Comment by Benjamin Muschko [ 24/Jan/17 ]

This is now tracked by https://github.com/gradle/gradle/issues/1164.

Generated at Wed Jun 30 12:32:00 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.