We have several java subprojects with tests. Before these tests run we need to create a special file for every subproject with its dependencies. To achieve this we iterate over the dependencies of the runtime configuration and write the paths to these dependencies in the file. The file is called plugin.xml and describes what a plugin is in our system and is necessary to run the tests in a production-like environment. For this we let all the subproject test tasks depend on the task that creates the file in every subproject. If we call the test task for every project like “gradle test” all the files are created with the valid paths. But if we call the test task for a special subproject like “gradle subprojectA:test” then the file of the other subprojects are created but they don’t contain runtime dependencies. From some debugging, I saw that the dependencies are not setup if you call a subproject also if it contains a dependency to a task of another subproject.
I have set up a test project that has a minimal setup that to show what the issue is. https://github.com/Dica-Developer/-gradle_empty_configurations
There are 2 subprojects a and b both are Java projects and have a runtime dependency defined. Both have a task defined called showDeps. It iterates over the runtime dependency and prints out the file.
If you call the task for subprojects for both subprojects the deps are listed like:
gw showDeps --rerun-tasks
> Task :b:showDeps
b deps
b -> /home/ms/.gradle/caches/modules-2/files-2.1/joda-time/joda-time/2.8.2/d27c24204c5e507b16fec01006b3d0f1ec42aed4/joda-time-2.8.2.jar
> Task :a:showDeps
a deps
a -> /home/ms/.gradle/caches/modules-2/files-2.1/joda-time/joda-time/2.8.2/d27c24204c5e507b16fec01006b3d0f1ec42aed4/joda-time-2.8.2.jar
If I call the task :a :showDeps which has a dependency on :b :showDeps the runtime dependency of project b is empty
> Task :b:showDeps
b deps
> Task :a:showDeps
a deps
a -> /home/ms/.gradle/caches/modules-2/files-2.1/joda-time/joda-time/2.8.2/d27c24204c5e507b16fec01006b3d0f1ec42aed4/joda-time-2.8.2.jar
Is this the expected behaviour or is this a bug?
How can we define such a dependency so that if we call a subprojects test directly the dependencies are available for another subprojects tasks?
I can’t reproduce what you’re describing with the provided sample project. If I run showDeps or :a:showDeps, I see the same output that matches your showDeps results. The runtime dependency is listed for both a and b in both cases.
@jjustinic Like I describe above If I run ./gradlew showDeps I get the expected result which is both tasks show their dependencies, but if I call ./gradlew :a:showDeps I don’t get the dependencies listed by project b. Could you please try to run the command ./gradlew :a:showDeps and paste the output. Thanks.
I found the reason why this happens. We have enabled org.gradle.configureondemand=true and this seems to lead to this situation. If I set it to false it will show the expected output. @jjustinic could you please verify that you have it disabled?
Is this a bug in the configuration on demand feature? I see that it is still marked as incubating.
This is the expected behavior for the configure on demand feature. The root project is always configured. The projects of the tasks requested at the command line are configured and standard project dependencies are supported. Task dependencies are supported only if you declare them via task path.
In your example, you cannot add a task dependency by directly referencing the task:
For configuration on demand to work, you must declare this task dependency by using the task path:
project(':a').showDeps.dependsOn(':b:showDeps')
Due to the strict requirements of the configuration on demand feature, it is generally a bad idea to turn this on for all projects by setting it in your GRADLE_USER_HOME/gradle.properties. You should only explicitly turn this on for projects that meet the requirements. Your issue here would have been immediately recognizable had the sample project explicitly enabled it, the command line included it, or the full output been included.
Thanks for your help. I will advise to disable it in our project.
Your issue here would have been immediately recognizable had the sample project explicitly enabled it, the command line included it, or the full output been included.
If I would know that this was the reason I would have told it before. I couldn’t solve it on my own that’s why I asked here. Your answer helped me to pin it down. Thanks again.
I didn’t mean to suggest you should have known the reason, but only that enabling the more dangerous experimental features for all builds on your machine is risky because any build can break unexpectedly. Specifically, the sample project didn’t actually capture the problem because there was some other configuration outside of the GitHub repo.