https://gradle.com/ logo
Join Slack
Powered by
This message was deleted.
# general
s
This message was deleted.
e
Oh yikes, just found this in the docs. I guess this is expected?
Copy code
As an example, the path a:b adds a project with path :a:b, name b and project directory $rootDir/a/b. It also adds the a project with path :a, name a and project directory $rootDir/a, if it does not exist already.
I can’t figure out why this would be desired functionality? Is there some way to bring in 
:auth:common
but NOT 
:auth
?
e
Copy code
include(":auth-common")
project(":auth-common").projectDir = file("auth/common")
t
why is it important that auth not also be a module? and yes, totally expected
e
It’s important because I'm working on demo apps for our project and the regular :auth module brings in a ton of transitive dependencies i don’t want to deal with
I’d like to not rename the project if possible, but i suppose that's an ok fallback if there's no other way
Oh also, the dependencies it's trying to bring in transitively aren’t in the settings.gradle when it's setup for the demo apps, so the whole thing doesn't build
I guess i don’t understand why it would work this way in the first place? Seems very surprising, and i can’t think of a single use case for it. Am i missing something?
t
why do you have auth:common nested under auth if there's no relation?
e
The honest answer is a poorly thought out legacy modularization structure
They are related, but :auth just isn’t needed in every scenario authcommon is
t
I hear you. This is just the way it is, there's nothing to be done about it. I think a good rule is that "intermediate" modules shouldn't have code. I see them more as organizational units than code-containing units
e
I 100% agree. We have ~500 modules and 95% of them work that way. We just have an annoying number of modules that don't.
Guess I'll be refactoring 🤷‍♀️
Still curious what the rationale for it working this way is. It just seems so weird.
➖ 1
➕ 1
t
sigh. you have my sympathy. maybe someone else knows a clever hack, but refactoring sounds more sustainable in the long run
e
it makes sense to me: every non-root project should have a parent, and the directory for each project is automatically derived from its path unless overridden
I am curious why you can't just leave :auth in place though. if you're trying to exclude it you don't depend on it, so… just don't build it?
e
I answered that earlier. It brings in transitive dependencies that i don’t want. They aren't even in the settings.gradle, so the project can't build.
e
external dependencies? it's fine if those aren't resolved as long as you don't build that subproject
e.g. if :demo doesn't rely on :auth then demobuild is fine even if authbuild will fail
e
No, internal
e
ok, then I don't understand how you're even in this scenario in the first place
e
For demo apps i want my settings.gradle to contain only the ~10 modules i care about, not the 500 modules in the project. This helps ide performance, especially syncing.
e
there's IDE settings to limit which modules it imports
e
That’s not a solution
e
it's a better solution than using the build in an unsupported way
e
People switch targets and having to go manually change ide settings is too much
That’s why i said I'd refactor it
It’s just legacy stuff that should have never existed in the first place
No one's fighting to keep it around, it’s just awkward to refactor
I was simply asking why this was unsupported
t
FWIW, I work on a project with 3500 modules and we have custom tooling to create small subsets dynamically. this works very well. there's a layer of indirection between our settings.gradle and the list of projects to include
e
by indirection do you mean something like a settings.gradle.local that gets applied to settings.gradle? or is there something more advanced going on?
asking cause i’m currently building exactly this and am just generating a local gradle script that has nothing but a bunch of 
include
calls so the actual settings.gradle doesn’t get modified at all.
e
@tony could you share more information about this? I work in a feature team with relatively small module count but I’m interested to see how this can be achieved by scripting the IDE
➕ 1
t
the basics of it you already grok, I think. we have a settings file. it doesn't have any includes. we have a gradle script named like "modules_all.gradle". That script is included by default with "apply from...". We have another, optional file. "modules_overrides.gradle." If that file exists, "apply from..." it instead. note that we only make this distinction during IDE sync. during CLI builds, we always use the full list. this decision predates me, but the idea is that we rely on configuration on demand for CLI, and only need this shortcut for improving IDE performance by limiting the number of modules it has to sync. we have a custom jvm app thst we use to generate the override file, or delete it upon request. this is the tricky part. I wrote some graph walking code to figure out the modules needed for the override file, based on the desired targets. this code makes a number of assumptions that I can assert are true for my repo, but may not be for yours, and takes some shortcuts like grepping for project dependencies in build scripts (vs trying to parse the scripts intelligently). it works extremely well. you could also use gradle itself to figure this out, but for a large project like mine, it's 400x slower than the regex approach, which completes in under 1s.
👍 1
e
Nice, this is exactly what I've built. Only difference is we don't have the modules_all.gradle. Mine basically does a 
find
for gradle scripts in the project dir. This takes an extra second or two, but I like the idea of not having any files to maintain.
Oh, mine doesn't include the cli vs ide difference either. Wouldn’t that impact configuration caching negatively? Or maybe intellij/android studio inject things into the build that break configuration caching between build types anyway.
One more question: how do you handle branch switching? Let’s say the developer has configured their project to bring in all dependencies of :app, then they switch to the latest from develop, where someone added a new module. Do they just get a failed build if they didn't think to run the script again? I’m considering setting up a git hook for this, but maybe you have a better idea.
Update: instead of a simple 
find
operation, i’m now walking the directory tree more intelligently (doesn’t recurse into src or build dirs) and the whole script to focus a project now takes ~200ms. Curious if you see a benefit to maintaining the 
modules_overrides.gradle
file vs making it all dynamic?
Open in Slack
PreviousNext
Powered by