Cannot load all projects: 'No projects in this build have project!'

[WallyCZ]

After upgrading to 1.4.0 (and also 1.4.1) I have following issue. When loading multiple gradle projects, that have some dependencies between them, one (or sometimes more) project fail to load with exception below. Sometimes helps reloading projects, that already were reloaded successfully. Also when I downgrade to 1.3.9.2, issue disappears. I am not 100% sure, that there is not some issue in our gradle configs, but in version 1.3.9.2 everything works as it should.

Issue 1

Requested project: ...

Stack trace:
org.gradle.tooling.BuildException: Could not run build action using Gradle distribution 'https://services.gradle.org/distributions/gradle-2.13-bin.zip'.
at org.gradle.tooling.internal.consumer.ExceptionTransformer.transform(ExceptionTransformer.java:51)
at org.gradle.tooling.internal.consumer.ExceptionTransformer.transform(ExceptionTransformer.java:29)
at org.gradle.tooling.internal.consumer.ResultHandlerAdapter.onFailure(ResultHandlerAdapter.java:41)
at org.gradle.tooling.internal.consumer.async.DefaultAsyncConsumerActionExecutor$1$1.run(DefaultAsyncConsumerActionExecutor.java:57)
at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:54)
at org.gradle.internal.concurrent.StoppableExecutorImpl$1.run(StoppableExecutorImpl.java:40)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:748)
at org.gradle.tooling.internal.consumer.BlockingResultHandler.getResult(BlockingResultHandler.java:46)
at org.gradle.tooling.internal.consumer.DefaultBuildActionExecuter.run(DefaultBuildActionExecuter.java:48)
at org.netbeans.gradle.model.GenericModelFetcher.getModels(GenericModelFetcher.java:168)
at org.netbeans.gradle.project.model.NbGradle18ModelLoader$ProjectModelFetcher.getModels(NbGradle18ModelLoader.java:375)
at org.netbeans.gradle.project.model.NbGradle18ModelLoader.loadModels(NbGradle18ModelLoader.java:68)
at org.netbeans.gradle.project.model.DefaultGradleModelLoader.loadModelWithProgress(DefaultGradleModelLoader.java:586)
at org.netbeans.gradle.project.model.DefaultGradleModelLoader.fixProjectLoadKey(DefaultGradleModelLoader.java:385)
at org.netbeans.gradle.project.model.DefaultGradleModelLoader.access$1500(DefaultGradleModelLoader.java:74)
at org.netbeans.gradle.project.model.DefaultGradleModelLoader$7.run(DefaultGradleModelLoader.java:441)
at org.netbeans.gradle.project.tasks.GradleDaemonManager.runNonBlockingGradleTask(GradleDaemonManager.java:35)
at org.netbeans.gradle.project.tasks.GradleDaemonManager.access$100(GradleDaemonManager.java:22)
at org.netbeans.gradle.project.tasks.GradleDaemonManager$2.execute(GradleDaemonManager.java:125)
at org.jtrim.concurrent.AbstractTaskExecutorService$FunctionWrapper.execute(AbstractTaskExecutorService.java:270)
at org.jtrim.concurrent.AbstractTaskExecutorService$TaskOfAbstractExecutor.execute(AbstractTaskExecutorService.java:340)
at org.jtrim.concurrent.Tasks$RunOnceCancelableTask.execute(Tasks.java:342)
at org.jtrim.concurrent.SingleThreadedExecutor$QueuedItem.runTask(SingleThreadedExecutor.java:919)
at org.jtrim.concurrent.SingleThreadedExecutor$QueuedItem.access$1200(SingleThreadedExecutor.java:898)
at org.jtrim.concurrent.SingleThreadedExecutor$Impl$Worker.executeTask(SingleThreadedExecutor.java:815)
at org.jtrim.concurrent.SingleThreadedExecutor$Impl$Worker.processQueue(SingleThreadedExecutor.java:827)
at org.jtrim.concurrent.SingleThreadedExecutor$Impl$Worker.run(SingleThreadedExecutor.java:861)
at org.jtrim.concurrent.SingleThreadedExecutor$Impl$1.run(SingleThreadedExecutor.java:453)
at java.lang.Thread.run(Thread.java:748)
Caused by: org.gradle.internal.exceptions.LocationAwareException: No projects in this build have project directory '...'.
at org.gradle.initialization.DefaultExceptionAnalyser.transform(DefaultExceptionAnalyser.java:74)
at org.gradle.initialization.MultipleBuildFailuresExceptionAnalyser.transform(MultipleBuildFailuresExceptionAnalyser.java:47)
at org.gradle.initialization.StackTraceSanitizingExceptionAnalyser.transform(StackTraceSanitizingExceptionAnalyser.java:30)
at org.gradle.initialization.DefaultGradleLauncher$1.create(DefaultGradleLauncher.java:101)
at org.gradle.initialization.DefaultGradleLauncher$1.create(DefaultGradleLauncher.java:93)
at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:90)
at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:62)
at org.gradle.initialization.DefaultGradleLauncher.doBuild(DefaultGradleLauncher.java:93)
at org.gradle.initialization.DefaultGradleLauncher.getBuildAnalysis(DefaultGradleLauncher.java:87)
at org.gradle.launcher.exec.InProcessBuildActionExecuter$DefaultBuildController.configure(InProcessBuildActionExecuter.java:102)
at org.gradle.tooling.internal.provider.runner.ClientProvidedBuildActionRunner.run(ClientProvidedBuildActionRunner.java:45)
at org.gradle.launcher.exec.ChainingBuildActionRunner.run(ChainingBuildActionRunner.java:35)
at org.gradle.tooling.internal.provider.runner.SubscribableBuildActionRunner.run(SubscribableBuildActionRunner.java:58)
at org.gradle.launcher.exec.ChainingBuildActionRunner.run(ChainingBuildActionRunner.java:35)
at org.gradle.launcher.exec.InProcessBuildActionExecuter.execute(InProcessBuildActionExecuter.java:43)
at org.gradle.launcher.exec.InProcessBuildActionExecuter.execute(InProcessBuildActionExecuter.java:28)
at org.gradle.launcher.exec.ContinuousBuildActionExecuter.execute(ContinuousBuildActionExecuter.java:81)
at org.gradle.launcher.exec.ContinuousBuildActionExecuter.execute(ContinuousBuildActionExecuter.java:46)
at org.gradle.launcher.daemon.server.exec.ExecuteBuild.doBuild(ExecuteBuild.java:52)
at org.gradle.launcher.daemon.server.exec.BuildCommandOnly.execute(BuildCommandOnly.java:36)
at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:120)
at org.gradle.launcher.daemon.server.exec.WatchForDisconnection.execute(WatchForDisconnection.java:37)
at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:120)
at org.gradle.launcher.daemon.server.exec.ResetDeprecationLogger.execute(ResetDeprecationLogger.java:26)
at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:120)
at org.gradle.launcher.daemon.server.exec.RequestStopIfSingleUsedDaemon.execute(RequestStopIfSingleUsedDaemon.java:34)
at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:120)
at org.gradle.launcher.daemon.server.exec.ForwardClientInput$2.call(ForwardClientInput.java:74)
at org.gradle.launcher.daemon.server.exec.ForwardClientInput$2.call(ForwardClientInput.java:72)
at org.gradle.util.Swapper.swap(Swapper.java:38)
at org.gradle.launcher.daemon.server.exec.ForwardClientInput.execute(ForwardClientInput.java:72)
at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:120)
at org.gradle.launcher.daemon.server.health.DaemonHealthTracker.execute(DaemonHealthTracker.java:47)
at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:120)
at org.gradle.launcher.daemon.server.exec.LogToClient.doBuild(LogToClient.java:60)
at org.gradle.launcher.daemon.server.exec.BuildCommandOnly.execute(BuildCommandOnly.java:36)
at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:120)
at org.gradle.launcher.daemon.server.exec.EstablishBuildEnvironment.doBuild(EstablishBuildEnvironment.java:72)
at org.gradle.launcher.daemon.server.exec.BuildCommandOnly.execute(BuildCommandOnly.java:36)
at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:120)
at org.gradle.launcher.daemon.server.health.HintGCAfterBuild.execute(HintGCAfterBuild.java:41)
at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:120)
at org.gradle.launcher.daemon.server.exec.StartBuildOrRespondWithBusy$1.run(StartBuildOrRespondWithBusy.java:50)
at org.gradle.launcher.daemon.server.DaemonStateCoordinator$1.run(DaemonStateCoordinator.java:246)
at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:54)
at org.gradle.internal.concurrent.StoppableExecutorImpl$1.run(StoppableExecutorImpl.java:40)
Caused by: org.gradle.api.InvalidUserDataException: No projects in this build have project directory '...'.
at org.gradle.initialization.AbstractProjectSpec.selectProject(AbstractProjectSpec.java:38)
at org.gradle.initialization.SettingsHandler.setDefaultProject(SettingsHandler.java:72)
at org.gradle.initialization.SettingsHandler.findAndLoadSettings(SettingsHandler.java:66)
at org.gradle.initialization.NotifyingSettingsLoader.findAndLoadSettings(NotifyingSettingsLoader.java:33)
at org.gradle.initialization.DefaultGradleLauncher.doBuildStages(DefaultGradleLauncher.java:119)
at org.gradle.initialization.DefaultGradleLauncher.access$200(DefaultGradleLauncher.java:32)
at org.gradle.initialization.DefaultGradleLauncher$1.create(DefaultGradleLauncher.java:99)
... 42 more

[kelemen]

Though given the stack trace I think there is probably an issue with the script, I would prefer fixing this to be more robust. However, I would need to see your settings.gradle (you can obscure directory names if you have to).

[WallyCZ]

Here it is, project names are modified, but I think it does not matter. Root projects are api, server1 and server2.
settings.gradle.zip

[kelemen]

Is there any reason to have many settings.gradle instead of simply one?

Anyway, the problem is that you are using new File('../core') which will resolve against the current working directory which is not defined to have a specific value. If you don't want to move from the many settings.gradle, you should write new File(rootDir.parent, 'core') instead.

[WallyCZ]

I am not sure how to do it with only one settings.gradle as to every developer does not have load all projects. One developer needs only api, second only server1 and so on. So with gradle all developers must have loaded all subprojects that exist in tree? :/

I tried replace all "'../" with "rootDir.parent, '" but it is still the same, server1 failed to load. With 1.3.9.2 it is ok.

[kelemen]

In NB, you can open any subset of subprojects you want. In Eclipse and Idea (I think) you can select which subprojects you want to import, so it shouldn't be an issue. Also, you may add org.gradle.configureondemand=true to your root gradle.properties to evaluate subprojects lazily. However, it is not really a big deal anymore, so you might not even want to bother.

[kelemen]

Anyway, I have tried opening your projects and they open without error for me. This also implies that my claim that your relative paths are resolved against the current working directory is almost certainly false. So, I think the plugin confuses the settings.gradle for some reason. If you try to run a task on a project which failed to load (you should be able to do that), the plugin should print something like:

Executing: gradle build
Arguments: [-c, <PATH>\settings.gradle]
JVM Arguments: [-Xmx512m]

I'm interested in if the <PATH> in the output is appropriate or not in your opinion.

[WallyCZ]

Meanwhile you write this last comment I tried to make only one settings.gradle and deleted those old ones. But then I've got another error - settings.gradle not found in the path where I already delete it. Reimporting projects did not help, still this error. So I reverted again to 1.3.9.2 and everything is ok again. It seems versions 1.4.x are not for me :)

[kelemen]

It could be that this is a cache problem. Can you try if removing all of your .nb-gradle/private/cache directories helps? (remove them while NB is not running)

There is also a "Load root project first" checkbox in the global settings: Options/Misc./Gradle/Build Script Parsing. You might want to try if turning it off helps or not.

[tiurikov]

Looks like I had the same issue. My project folder was located quite deep in the file system, so it's absolute path contained too many symbols. I moved my project several folders up and it helped.

[Gontran08]

I have the same problem, except that I have an absolute path in the error message and that I didn't configured it anywhere. I have to delete Netbeans cache to fix the problem. It happened multiple times to me.

[kelemen]

Is it possible that the project is in multiple settings.gradle?

[Gontran08]

I had multiple settings.gradle, but I removed them after seeing this thread. There was only names for the subprojects.

[kelemen]

I assume it still happens to you after removing the other settings.gradle. If that is the case, it is even more strange. If it happens to you again, can you send me the whole multi project build without sources including the .nb-gradle directory? If not, can you at least send me the content of the .nb-gradle/private/cache directory?

[Gontran08]

I had to delete the cache of Netbeans, but it didn't happen since then.

[kelemen]

By NetBeans cache, do you mean the .nb-gradle/private/cache directory?

[kelemen]

Also, if you feel up to it, you might try to do some debugging (because I cannot reproduce this issue). See the wiki page for how to setup the IDE for debugging.

What is particularly interesting is what happens in DefaultGradleModelLoader.fixProjectLoadKey.

[Gontran08]

I mean /home/$USER/.cache/netbeans/8.2 on Ubuntu.

[kelemen]

That is very strange because this plugin does not store anything there related to loading the project. I think that something else fixed your problem (maybe because you also had to restart NB when deleting the cache).

[kelemen]

Having no better idea, I read through the code multiple times and the only thing I can imagine is the start of DefaultGradleModelLoader.fixProjectLoadKey. If my hypotesis is true, then anyone experiencing this issue should see this in the IDE log:

Failed to load root project for

It would be nice if someone could confirm or refute this. Regardless, I will adjust that part of the code because it is definitely not very reasonable.

[Gontran08]

I'll try to find time to test it tomorrow.

[kelemen]

I have also pushed an attempt to fix this issue, so you might also try to build the plugin from the sources (after you see this bug appearing again).

[psimonazzi]

I experience very similar behaviour. I see 'Failed to load root project for...', and deleting the global Netbeans gradle cache solves the error (temporarily).
I reference the same gradle project in several settings.gradle, and it seems that Netbeans sometimes mixes up the paths, looking for a settings.gradle in the path of another. In the cache .properties files I see that the 'settingsGradle' property has the wrong path.
I'll try the fix and let you know.

[WallyCZ]

1. I tried build and test newest version from repo - still the same
2. I tried delete .nb-gradle/private/cache - still the same
3. I tried delete %USERPROFILE%\AppData\Local\NetBeans\Cache\8.2\ and everything started to work correctly so thanks to @Gontran08 for great tip!

UPDATE: It seems that deleting only directory %USERPROFILE%\AppData\Local\NetBeans\Cache\8.2\gradle\ is sufficient as psimonazzi noticed

[kelemen]

Can you send me your messages.log from the session where you were using the version built from master and this issue happened?

I completely forgot about that cache, I will review it. Thanks it was a great help.

[WallyCZ]

Sorry, it is lost now - Netbeans keep only 3 last log sessions and I also lost that broken cache directory so I can't reproduce it again. But maybe someone else can catch it.

[kelemen]

Another question: Do you have "Load root project first" checked or unchecked in the global settings?

[kelemen]

Anyway, given that removing the cache helps, I would guess that core issue is that at some point you had a project part of a particular build but removed it later and the plugin couldn't recover from this.

[WallyCZ]

I have "Load root project first" checked. Maybe I will be able in few days on another computer save that broken cache directory and record messages.log from master version if nobody does it sooner...

[psimonazzi]

I prepared a minimal test with 3 projects: gradle-test.zip

Open the projects, then edit project-B/build.gradle (just add a comment and save), then:

• "Reload Project" command on project-B
• "Reload Project" command on project-C

Now running any task on a project should throw an error, and in logs you can see that Netbeans is looking for settings.gradle in the wrong path, for example building project-C says:

Executing: gradle build
Arguments: [-c, /opt/gradle-test/project-B/settings.gradle]

Also in Netbeans cache files (.cache/netbeans/8.2/gradle/settings-gradle) the settings.gradle path is wrong.

[psimonazzi]

I don't know if it could break other use cases, but I think if a project has its own settings.gradle, it should always take priority over the root project one? As far as I understand this is what gradle does...

[kelemen]

@psimonazzi Though the process is not exactly deterministic, I was able to reproduce the issue. So, I'll definitely fix this (hopefully, this week).

I assume you mean by "has its own settings.gradle" that settings.gradle is directly in its project directory. Though, I can make a case for that, that is only a corner case. Your setup of every project having its own settings.gradle is relatively unusal and I don't think that is the intended way to organize the build. The current intended behaviour is this:

• If you have a root project opened and its project hierarchy contains another project, then that root project is assumed to be its root (and the one defining its settings.gradle).
• If you have multiple root project opened whose project hierarchy contains a particular project, then one will be choosen at random (i.e., it is undefined which one becomes its root). It is completely reasonable to prioritize between them by choosing the one closest to the project directory of the actual project but it might be some extra work for the plugin. I will evaluate, if I can get away with this prioritization with a cheap trick but I'm not sure.

Anyway, I would recommend everyone against having separate settings.gradle for each subproject (even if this issue was fixed), for the following reason:

• It is much more efficient to load the projects, if projects share their settings.gradle (i.e., their are in the same multi-project build), because I can load them all at once. Unlike when they do not share their settings.gradle, in which case (in the worst case), I have to ask Gradle to load them one by one.
• When loading projects in a single run the plugin can optimize memory consuption better by sharing immutable string (and similar immutable) references. This can reduce the memory footprint by hundreds of MBs.
• It is extremely difficult to make NB deterministic in its choice of settings.gradle (and therefore task execution) and you should probably avoid non-determinism if you can.

[kelemen]

I believe that I have found the bug, and it should now be fixed in master. If you are already experiencing this issue, you might need to manually delete NetBeans' cache (or at least the "gradle" folder within it) because at the moment, the plugin will not always self heal from this bug.

[psimonazzi]

I tested the master and it seems to be fixed indeed.
Thanks for the gradle suggestions too.

[WallyCZ]

Thanks for fix. We are now double save since we also switched to one root settings.gradle

[aplatypus]

Hello -- I had this problem today after moving some folders and cleaning-up temporary directories, etc. The problem exhibits itself on the command line. Don't need Netbeans to see this issue.

After some poking about I removed the contents of the Gradle cache and I am now free tp build on the command line.

rm -r $GRADLE_USER_HOME/caches/*
gradle build --refresh-dependencies

I refreshed dependencies to make sure things are up to date.