https://dl.dropboxusercontent.com/u/646106/gradle-run-1.txt has the results of running ‘gradle -a test --configure-on-demand -debug’ in one of 495 submodules of a gradle build, which fails with the error: Configuration with name ‘default’ not found
This build is the result of a conversion from a rather convoluted ant build, and the complications have us turning transitive dependencies off for building, but turning it on for running unit tests.
We’d noticed that every single build insisted on configuring all 495 projects, even when building just one, so made a change intended to take advantage of --configure-on-demand. Now we get this failure, whether or not that flag is set.
So I would like to know what is wrong, and if there is a better way to handle building individual modules without incurring the cost of configuring them all.
Sounds like a project dependency can’t be resolved because the target project doesn’t have a ‘default’ configuration, e.g. because it doesn’t apply the ‘java’ plugin or a similar plugin. (The ‘default’ configuration is added by the ‘base’ plugin. Plugins such as the ‘java’ plugin add artifacts (e.g. the generated Jar) to this configuration.)
‘–configure-on-demand’ is currently the best way to avoid unnecessary configuration in large multi-project builds. It’s also important to write build scripts and plugins in such a way that all expensive work is performed in the execution phase, rather than the configuration phase.
How do I know what is done in which phase?
Task actions (e.g. ‘myTask.doLast { … }’) are evaluated in the execution phase. Most other code in a build script is evaluated in the configuration phase. Ultimately, the Gradle Build Language Reference is expected to document the cases where a block of code (i.e. closure) isn’t evaluated immediately (i.e. not in the configuration phase).
Is it possible to delay setting ‘version’ until the execution phase? Mine is computed by querying git.
How do I track this “Configuration with name ‘default’ not found” problem down? The debug output is useless, the info output is useless, and gradle, although it must know where in the script it found the problem, doesn’t tell me.
You should at least see which task encounters the problem, and then you can check which configuration(s) this task consumes. The actual problem lies with a (possibly transitive) project dependency or external dependency of this configuration, and can’t be easily tied to a script location. Most likely the problem is caused by some project declaring a project dependency on another project that doesn’t declare a ‘default’ configuration. For reasons why this might happen, see my first post in this thread.
In my case, I had a git submodule artifact in my project folder, left there when switching between branches: one branch has the artifact and the other does not. Unfortunately git doesn’t remove sub-module folders when switching branches.
After a lot of headscratching I finally saw it. The real problem here I noticed, is that gradle searches all folders on disk. It even issues warnings for them if they contain build.gradle files. But actually they are NOT part of the declared project (settings.gradle) and so I believe they should NOT be examined at all!
Because gradle was examining folders not mentioned in settings.gradle, it was actually failing for NO REASON at all.
I tracked my problem down as well - and again, it is absolutely something gradle should have caught. There was an include in the settings.gradle file, but no build.gradle file in the referenced directory at all. You’d think that would be a basic sanity check.
(Sub)projects without build.gradle file are not considered a problem. It is often enough to enumerate set of subprojects in settings.gradle and then apply some common configuration from a one place. You can add a check like this but at this point I am not sure how to make it working for common cases (i.e. how to tell if it is missing by design or by fault).
Radim, in my case (above), gradle went off looking at folders NOT in the settings.gradle, which would be fine as long as it doesn’t fail execution if it runs into trouble.
Frankly, I’m surprised that gradle is behaving this way in a project situation where there is a settings.gradle, the folders mentioned by it should be the ONLY ones gradle looks at.?