I find it quite natural that the Groovy dependency needs to be declared explicitly in this case. First because Gradle needs to know which Groovy compiler it should use, and second because anyone writing Spock tests uses Groovy directly. In such a case one should also have a direct dependency on Groovy. In retrospect, Spock's dependency on Groovy should probably have scope "provided", emphasizing this point of view.

Although one could make Gradle search the class path for a Groovy compiler, I wonder if it is the right thing to do. And as soon as the code uses some Groovy API, it needs to have a direct dependency anyway. That is, unless Gradle adopts Maven's dubious semantics for transitive dependencies (compile + compile -> compile).

I understand this line of argumentation from the implementor's perspective, but from a user's perspective, I just want to use Spock with the contained Groovy version (note: this is a plain-Java project).

Specifying that version myself requires additional knowledge and thus makes Spock more difficult to set up than need be.

I see the point from both sides. In general we want to deprecate the groovy configuration at one point. Instead Gradle would be smart enough to parse the compile classpath for a Groovy lib which is then used for the compiler. The question is whether transitive dependencies should be searched for that is a different one. I think not as default. We want to encourage more explicitness and less fragility.

I think the case of Spock is a different one. One should be able to declare that Spock is used. Then we could do the right thing automatically (how we do it would be an implementation detail).

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!

Thanks again for reporting this issue. We haven't heard back from you after our inquiry from November 15th. We are closing this issue now. Please create an issue on GitHub if you still feel passionate about getting it resolved.