https://gradle.com/ logo
Join Slack
Powered by
When using composite builds my individual root pro...
# community-support
a
When using composite builds my individual root project do not discover the tasks of the subprojects anymore. So I do not mean that I can not access tasks from includedBuilds, because that is by design. But I mean that I have a composite build (libs) with subprojects in there (asset-mapper). And the libs project does not allow me to execute the tasks. See thread for what I mean.
Copy code
./gradlew projects

...
Included builds
+--- Included build ':apps'
\--- Included build ':libs'
...
Copy code
./gradlew :libs:projects

...
Project ':libs'
\--- Project ':libs:asset-mapper'
     \--- Project ':libs:asset-mapper:asset-mapper-core'

Included builds
+--- Included build ':apps'
\--- Included build ':libs'
....
Copy code
./gradlew :libs:tasks

....
test - Runs the test suite
....
Copy code
./gradlew :libs:test

FAILURE: Build failed with an exception.

* What went wrong:
Cannot locate tasks that match ':libs:test' as task 'test' not found in project ':libs'.
and this works (obviously):
Copy code
./gradlew :libs:asset-mapper:asset-mapper-core:test
With "normal" projects (so no composite builds) this works just fine. And it is also how I expect Gradle to behave. That subproject tasks are discovered and executed if they exist when calling it at toplevel. I assume I have a config error somewhere, but the 
libs
project does not include any other builds or dependencies. And it is the only 
includeBuild
at root level.
a
🙏 1
a
Great! For once it is not me 😄 Thanks!
v
That's not exactly the issue. That issue is about doing it programmatically, not manually from command line. From commandline top-level or not does not matter. What matters is path or no path. If you execute 
test
in some project (does not have to be the root project) it executes 
test
in that project and all descendents where it exists. If you execute 
:test
it only executes the 
test
task of the given project, in this case the root project. If you call 
:libs:test
, that is with path and so it does exactly what you asked for, running the 
test
task in the 
libs
project (not build). For what you want, you have to call without path, so 
gw -p libs test
.
a
Haha thanks. Makes sense. So it was me.
However, it is a bit confusing that 
./gradlew :lib:tasks
shows me the 
test
task as well. I understand why it happens, but it implied that 
:lib:test
is available when it isn't. It is when using 'normal' projects, but not with composite builds.
v
Yeah, that is indeed a bit misleading. Maybe worth a feature request or issue report to not show such catch-all tasks when reporting from an included build.
Hm, no, actually this has nothing to do with composite builds actually, within one build it is just the same
If in the Geb build I do 
gw doc:tasks
I see 
asciidoctor
, but calling 
gw doc:asciidoctor
does not work, calling 
gw -p doc asciidoctor
would work though.
Without 
--all
, the 
tasks
task displays which tasks would be exectuable if you execute Gradle in that that project's directory without specifying an explicit path.
With 
--all
it shows the explicit individual tasks of the projects.
So I'd say the output is fine and consistent, even if it might sometimes be confusing at first sight. 🙂
a
You know, Gradle appears complicated. But after 3,5 years in the trenches with yarn, vite, npm, pnpm, etc I choose Gradle above everything else everytime if I'd have the option.
👌 1
2 Views
Open in Slack
PreviousNext
Powered by