"Cannot run tasks for included builds"

[sc1478]

Buildship is telling me it can't do the included builds.

Yet, if I go to the command line in the same directory and run ./gradlew clean, gradle has no trouble doing the job. I tried refreshing the Gradle project from the Eclipse menu, that did not help

Gradle version 4.0
Buildship version Buildship: Eclipse Plug-ins for Gradle 2.0.1.v20170302-1039 org.eclipse.buildship.feature.group Eclipse Buildship

Eclipse tells me no updates are available.

[donat]

This is a limitation of Gradle itself, as you can't directly address tasks from the included builds.
Basically, when you execute gradle foo on a composite build, then those tasks will be executed from the included builds that produce artifacts required by foo. You'll find more information in the user guide.

[sc1478]

This is not a composite build. It is a straightforward multi-project build. Are you telling me that the new version of Gradle will take a multi-project build and assume it is composite without any change to the build. Is there any way to turn this "feature" off?

[donat]

Nope, the tasks should be disabled only for the included builds. I'll have a look how could you end up in this phase. Could you create a sample project exhibiting the problem so that we can use it for the investigation?

[oehme]

This usually happens when a user runs Add Gradle Nature on a subproject. Our included build detection currently compares the connectionProjectDir against the root project dir, which fails in this case.

Our detection could instead use the GradleBuild model to determine whether a project is from an included build or not.

Also, we should really finally add proper root project detection, so we use that as the connectionProjectDir, even when the user selects a subproject when adding the nature.

@sc1478 sorry for the techno-babble, these were just some implementation hints for @donat

[sc1478]

Also, your reply that "this is a limitation of gradle itself" seems to ignore my initial statement

Yet, if I go to the command line in the same directory and run ./gradlew clean, gradle has no trouble doing the job.

Do you still need a sample from me? I'm not clear at this point.

[sc1478]

Is something needed from me to make progress on this issue?

It's still an issue in Buildship-2.1.1

I am surprised this issue doesn't have higher visibility.

[fbazbo]

I'm seeing the same issue, but it was working fine until I just upgraded from Gradle 3.5 to 4

[sc1478]

Yes, it's not an issue when using 3.x gradle wrapper, only with 4.

[fbazbo]

Actually, I have one multi-project with 4.0 that works and one that doesn't. Not obvious what's the difference between them...

[fbazbo]

Ended up closing all the projects and deleting from eclipse, then "Import Existing Gradle project" and reopened the root project. Now they all show green again...

[sc1478]

Thanks for that tip. It does work.

[kcclaas]

I still have this error as well. I've tried closing, deleting, and re-importing the projects (both by importing the root, and by importing the sub-projects first), but I still can't run tasks for the subprojects. There are green gear icons next to them (unlike the grey ones in the original screenshot here), but double-clicking them doesn't do anything, and right-clicking them gives the same "Cannot run tasks for included builds". These are standard multi-project builds.

I can run the builds/tasks from the command line, and can create run configurations in eclipse to do the same as a work around for now. If I import the subproject first, I can run tasks for it up until I import a project that depends on it.

[oehme]

@kcclaas any chance you can reproduce that with a small example on GitHub?

[kcclaas]

Sure, I'll see if I can come up with something tonight.

[kcclaas]

@oehme I've created a repo here that exhibits the same issue. Let me know if there's any additional information I can provide to help.

[oehme]

Thank you, I see what the problem is now - the message is wrong. It should read "Cannot run task selectors in non-standard project layouts". In a flat layout like yours, Gradle cannot find the root project when launched from a subproject. This is why we can't make "task selectors" (run this task here and in all subprojects) work.

"Project tasks" (run this task only in this subproject) should work though. They are hidden by default, but you can show project tasks by checking the correspdoning option in the drop-down menu of the tasks view.

[sc1478]

I wish I could provide you a sample of the original project that caused me to open this issue, but the problem in that case went away upon reimporting it into Eclipse. I can tell you, though, that my project followed the conventional layout pattern in which subprojects were contained in subdirectories of the project root directory.

[kcclaas]

@oehme Oh, cool. Thanks for explaining that, I didn't even realize that menu was there. Everything works for me as you said.

[donat]

As the problem with the incorrect error message is fixed in #539 and @sc1478's problem is not reproducible, I'm closing this issue as fixed.

[oehme]

The problem that @sc1478 faced is very likely caused by what I pointed out here: #511 (comment). So I'd keep this issue open until we have investigated whether this is the case.

[oehme]

@totszwai You have a flat project layout, please activate the Show Project Tasks option in the tasks view. Task Selectors don't work, for the reasons I outlined above.

[totszwai]

Ah crap it automatically greyed out all the tasks again. @oehme where exactly is Show Project Tasks? I see no such thing under the Gradle Tasks panel, there is nothing on the top right corner of the panel, and nothing when right clicking on the nodes nor anywhere in the panel either... I also checked in Windows > Preferences > Gradle

[totszwai]

Never mind, found it, wow...

[oehme]

@donat I think we should reconsider what we display in the tasks view. Maybe we could get rid of the "show project tasks" option and instead show project tasks automatically if task selectors aren't available. And if task selectors are available we could add an option to the context menu like "run only in this project". That way users never have to switch an option based on their project layout, but always get the best possible support we can give.

Long term we should fix Gradle to support task selectors in non-standard layouts. That would be great for composite builds as well.

[kuniss]

For those who had a similar problem in include builds - Check the file .setting/org.eclipse.buildship.core.prefs whether the connection.project.dir property is empty.
If not, make it empty.
In my case the grayed tasks become green again. 😄

I my case this (non empty property) happens when turning back from included projects to non-included projects...

@donat @oehme Not sure, whether this may help to solve the issue too. In facts, my issue comes from an out dated .setting/org.eclipse.buildship.core.prefs .

Version used:
Eclipse Neon,
Buildship 2.2.0.v20171211-1401 Buildship: Eclipse Plug-ins for Gradle 2.1.2.v20170807-1321

[oehme]

@kuniss You shouldn't need to manually edit the preference file. Just refreshing the root project should do the trick. Any chance you can reproducibly get back into the broken state?

[kuniss]

The question is, what is the root project? I do not have such thing like a parent project in Xtext created projects (I know it from)...
Is it those which does not have other included projects?

[oehme]

The root project is the one where your settings.gradle file lives.

[kuniss]

I guess you may reproduce easily by checking out projects javapos-contracts, javapos-controls, javapos-config-loader from https://github.com/JavaPOSWorkingGroup.
Initially all projects are not include projects.

However, if you add

disableIDEDependencySubstitution=

to your gradle.properties (which enables include nature of the projects, see project's settings.gradle), refresh Gradle tasks on javapos-contracts and then removes the line above again, the next refresh of Gradle tasks will make the tasks grey.

[kuniss]

.. I have a settings.gradle file on each of the projects as they can be checked out independently and in different sets.
Maybe, this is the issue. However, how to get this running otherwise?

[oehme]

Okay there was a terminology issue: Those are included builds. So you are creating a composite and then trying to split it back apart and that is not working, did I get that right?

[kuniss]

Right, I switch between composite builds and not composite builds. I called it included builds as I created them using

	if (file('../javapos-contracts').exists()) 		includeBuild '../javapos-contracts'

Is included build not the right term for that?

[oehme]

You said "included projects" earlier, which is why I thought you had this problem in a simple multi-project build.

I think this gives us enough information to reproduce and find a fix, thanks Denis!

[kuniss]

As you consider it as an issue 😄, here is another GUI side effect coming from it, I guess:

Same projects are listed several times. I saw up to 4 equal projects some times.

[ams-tschoening]

I have a composite build always and the same problem with multiple included builds showing in "Gradle Task". All my projects live under the same workspace root in Eclipse and none of these projects use any subprojects and only one build.gradle and settings.gradle located in the project root.

Eclipse-Workspace
+---de.am_soft.docbeam.client.api
+---de.am_soft.docbeam.client.impl
+---de.am_soft.docbeam.raw.server
+---de.am_soft.documentbeam
+---de.am_soft.util

It's 4 times .api and 2 times .impl, because .api exists as a project itself in Eclipse and is included in 3 other projects. .impl exists as a project itself as well and is included in one other project only. If tasks can't be executed on included projects anyway, it might be a good idea to not show them at all.

I still don't understand one thing and would be grateful if you could explain the expected behaviour and what the actual problem is (one more time):

I understand that one can not execute tasks of included builds in a composite build because of Gradle itself. I think this makes even sense to me. So in my example above with 4 times having .api, I can't execute tasks for 3 of those because those actually represent entries for some included builds and shouldn't even be visible at all.

What I don't understand is why I can't execute tasks on the 1 .api entry that seems to represent the Eclipse project itself, independently of any other includeBuild in some other project. In the following screenshot all tasks are disabled instead:

When I'm executing gradlew clean at the shell directly in the project folder of my Eclipse .api-project, that project is cleaned properly. So there can't be any limitation of Gradle itself from my understanding.

So what is the expected behaviour in such a setup? Should I be able to issue tasks for the 1 .api project which, while used in a composite build, is somewhat independent as well? If not, why?

Thanks!

[oehme]

There shouldn't be 4 times the same project in the tasks view. Please share a reproducible sample.

[ams-tschoening]

Find my reduced examples at the bottom, it seems things depend on project-import-order in Eclipse a bit and it doesn't seem to make a difference if I delete the Eclipse-related files or not.

Plugin-Tests.zip

What about the statement for composite builds? Should one be able to execute tasks of included builds on those included builds only or not?

I would like to be able to sometimes build individual projects regardless of if they are used in a composite build or not and from my understanding that is exactly the use-case for composite builds.

[oehme]

Should one be able to execute tasks of included builds on those included builds only or not?

That's currently not possible, as Gradle provides Buildship no way to address those tasks.

Note that there is a difference when you jump into the project directory on the command line - in that case you are just building that single build. But when you've imported a composite into Buildship, that included build is always treated as included. There is no way to treat it as standalone, except for removing it from the composite.

[ams-tschoening]

There is no way to treat it as standalone, except for removing it from the composite.

Couldn't Buildship provide some GUI or context menu which would let me tell it to simply do what I would otherwise need to do on the shell manually?

It even already knows all the available tasks and could put an entry into the already available context menu for the disabled tasks. It could even simply use the shell if it's not possible otherwise, users would still benefit because they wouldn't need to leave Eclipse manually.

[ams-tschoening]

Another use-case for which it would be useful to be able to run individual task on included builds only and which as well only make sense for individual projects: I'm using gradle-eclipseconfig to manage project settings regarding the current charset etc. As one can see in the following screenshot, I'm unable to run the necessary tasks for the individual projects from the GUI only because it is included in some others:

The funny thing is that the including project doesn't even provide these tasks in its view.

[andreabisiach]

I am experiencing the same problem with composite build and greyed out tasks.
I have imported the same composite build project in Eclipse and IntelliJ and the result is quite different. In Eclipse I cannot run any taks configured in the included builds. In IntelliJ that works fine.
I have noticed that this problem occurs "some time" after the projects have been worked one.
Removing them from the workspace and reloading them does not solve the problem.
Any idea?
See the pictures

The weird thing is that if I close the one of the eclipse project incluede as build, the tasks become active

[andreabisiach]

Should one be able to execute tasks of included builds on those included builds only or not?

That's currently not possible, as Gradle provides Buildship no way to address those tasks.

Note that there is a difference when you jump into the project directory on the command line - in that case you are just building that single build. But when you've imported a composite into Buildship, that included build is always treated as included. There is no way to treat it as standalone, except for removing it from the composite.
Hello @oehme
Is the above statement still current. I have done a bit of test and it seems hat IntelliJ works perfectly fine with composite builds. In addition, closing included projects in eclipse, seems to trigger exposing the tasks in the included builds. Seems like a bug.
Please see my earlier posts with pictures

[maciejmiklas]

@kuniss I'm now Version: 2019-12 (4.14.0) and your solution works fine. Without it this whole composite build is totally useless, because it's not possible to generate facets for included projects.

[ams-tschoening]

Couldn't Buildship provide some GUI or context menu which would let me tell it to simply do what I would otherwise need to do on the shell manually?

In current versions of Eclipse and depending on the distribution chosen, this is easily possible without any additional support from Buildship or plugins by simply using Show in local terminal of the context menu of projects.

This opens a new view with a shell in which Gradle can be executed as needed without leaving Eclipse, with the important point being that one doesn't need to navigate to the concrete project of interest manually anymore.

If that terminal is not provided by default, it can be installed using the marketplace or some alternatives chosen.

[donat]

Heads-up: Gradle 6.8 will allow task execution in included builds. I'll adjust Buildship to support this feature.

[donat]

Gradle 6.8 and Buildship 3.1.5 is released.