https://gradle.com/ logo
Join Slack
Powered by
Hello, let's say I have a Gradle project called "*...
# community-support
a
Hello, let's say I have a Gradle project called "*root-project*" that includes another gradle project "*feature-a*" by includeBuild (Composite builds). Let's suppose this "feature-a" Gradle Project include two gradle subprojects, a library and a sample-app. Is there a way to hide feature-a:sample-app from root-project ?
v
What do you mean by hide? Hide in what context? And why? Can you elaborate a bit more on your use-case?
a
Sure, I am trying to see if we can allow a team to have its own gradle project inside our monorepo so that they can have as many modules as they want into it. But when their project is imported into the one of the main app, let them expose only the modules they want to expose...
So kind of having private modules that are not included when a gradle project is included into another one
I guess that would require another include function on projects if something like that existed
v
Never tried something like that. Maybe they need to skip the publication of the respective feature variants like shown for the test fixtures variants on https://docs.gradle.org/current/userguide/java_testing.html#sec:java_test_fixtures last example on the bottom of the page.
a
Thanks I'll have a look
e
if 
:feature-a:sample-app
is just a leaf, perhaps you could change it not to provide any consumable configurations. then it won't provide anything as a dependency
v
How would you do that? If anything applies the 
java
plugin, you already have consumable configurations and I don't think you can remove them. That's why I said that the skipping might help.
e
Copy code
configurations.all { isCanBeConsumed = false }
v
I see. This might work for the time being, just with a warning. But this will fail I think with Gradle 9, as you will not be allowed to change the role of a configuration.
e
I suppose there's also
Copy code
configurations.all { isVisible = false }
although that's something I have less experience messing around with
v
Oh, it (changing consumable) already fails with 8.8 actually for certain configurations:
Cannot change the allowed usage of configuration ':mainSourceElements', as it was locked upon creation to the role: 'Consumable'.
This role permits the following usage:
Consumable - this configuration can be selected by another project as a dependency
Ideally, each configuration should be used for a single purpose.
The 
visible
flag name is misleading afair and does not do what it suggests it might do.
Yep, quickly tried changing visible is useless for that.
a
Maybe there's a way to check that the root project is actually the one including the module, and do it conditionally this way? Something like
Copy code
if (!rootProject.isInCompositeBuild)
    include(":sample-app")
}
v
And as I was testing, the 
skip()
also does not work for that
Something like
You could, but it is very questionable whether you should. 😄
e
yeah I vaguely remember visibility doing something legacy that wasn't really relevant anymore, just didn't remember the details
v
Maybe it would be better to have one build for 
sample-app
that also includes the build with 
library
. Then when the main build includes 
library
, there is no 
sample-app
to hide
If you want to do that conditional including, you need to check 
gradle.parent == null
or something like that
a
Interesting
Yeah indeed it would have been better to be able to clearly define visibility when included into a composite build
e
if it's just the sample app though, I think another common(-ish) solution is to make it a standalone build (not `include`d by the root build) that `includeBuild`'s the "root" build
v
Isn't that what I just suggested? Or something else I did not get right?
e
ah, that is what you said, I just didn't parse it the way you meant
a
I see, like a chain of projects but not one with both
v
root-build => includeBuild feature-a feature-a => include library sample-app => includeBuild feature-a
a
Yup, should work, but that means a team need to juggle between multiple projects
v
so root and sample see library, but neither sample sees root nor root sees sample
Juggle between multiple projects?
a
Ah no they open only the one of the lib + app
Sounds actually good!
e
does it need to be that complex? just
Copy code
// /settings.gradle
include("library", "feature-a")
Copy code
// /sample-app/settings.gradle
includeBuild("..")
anybody working in 
/sample-app
will see all of the root project too. but if you're working in 
/
you don't see 
/sample-app
v
I don't think sample-app should see root as far as I understood
But I think he got the idea and can work out the details 🙂
a
Yup thanks a lot to both of you 💙
👌 1
v
And library is a project in the feature-a build. And root build includes feature-a and some others from other teams.
At least that is what I understood. Might be majorly wrong of course. 😄
a
Well I know I'm pushing it here... 😅
v
p-p-p-push it real hard
Open in Slack
PreviousNext
Powered by