Cannot use project dependencies in a script classpath definition

Help/Discuss
1

I need to write a custom task that depends on a subproject without pulling the subproject in a library on its own:

| root
|
+-- utils
+-- gradle_tasks (depends on utils)
+-- generated_java
+-- app (depends on utils, generated_java)

Here is what I put in the build.gradle of generated_java

buildscript {
    dependencies {
        classpath project(":gradle_tasks")
    }
}

task regenerate(type: GenerateDatabaseObjectsTask) {
    // ...
}

But when I run gradle generated_java:regenerate it complains:

FAILURE: Build failed with an exception.

* What went wrong:
A problem occurred configuring project ':generated_java'.
> Cannot use project dependencies in a script classpath definition.

I put the code on GitHub

1 Like
2

I double this. Is there any workaround?

3

You might need to split utils and gradle_tasks into their own separate multi-module build under the buildSrc directory (using buildSrc/build.gradle and buildSrc/settings.gradle). Then, from the main gradle build you could refer to the buildSrc artifacts using group:artifact:version notation rather than project(...).

Never tried it myself but worth a try

4

In my project I already moved from buildSrc/ to flat multi-module structure, where there is one module which is a Gradle plugin, used in other modules. Purpose for that was to release that Gradle plugin also by itself.

Actually class deps to other modules work with older Gradle versions and were broken only recently. I think this commit is relevant: https://github.com/gradle/gradle/commit/9f2d830543a349bb41035eb957207fd16efb60a5

5

This problem becomes pressing, because recently I’ve encountered Java compiler bug, which is fixed in Java 9. But I cannot use JDK 9 with Gradle 2.5 (apparently the last Gradle version which doesn’t have this limitation, because it doesn’t recognise JDK 9:

Could not determine java version from '9-ea'.

6

@leventov have you found a solution for your issue?

I am currently in the same situation: I’d like to have a multi project in which there is a gradle-plugin defined (the main artifact of the whole project). In addition there is a framework taking leverage of the plugin (only for testing though), as they go hand in hand.

I suppose I could put the gradle-plugin under root/buildSrc and define some artifact release configuration int the corresponding build.gradle?

7

I think the path forward is having a plugin in a separate build and using composite builds: https://docs.gradle.org/5.3/userguide/composite_builds.html