Office Hours — Today, December 1

← Tuesday, November 29

Dec 1
3:50 PM
Mark M.
has entered the room
Mark M.
turned on guest access
4:20 PM
Steve T.
has entered the room
Steve T.
Hi Mark!
Mark M.
hi, Steve!
how can I help you today?
Steve T.
I have a question regarding gradle
View paste 
I have three flavors A, B, and C in my main module.
The main module depends on a bunch of library modules.
I set dependency versions (e.g., supportLibraryVersion) in my `rootProject.ext.*` and then compile them in each module’s build.gradle file.

Is it possible to override a value in `rootProject.ext.*` depending on the flavor of the main module?

For example, I would like to use a different version of the support library for flavor A (24.2.1) and B/C (25.0.1), and have that value used when compiling all of the project’s modules.

If not, is there any other solution you can think of that will give us the desired results?
4:25 PM
Mark M.
well, your dependencies can be by flavor, AFAIK
I usually only vary dependencies by build type (e.g., debugCompile, releaseCompile)
but AFAIK you should be able to do flavor1Compile, flavor2Compile, etc.
Steve T.
Yes, but that's only in the one module with those flavors
Not the other library modules in the project
Mark M.
well, the only way to vary dependency rules is by build type or product flavor
if your libraries lack those, you will need to add them
then figure out how to get the main module's flavors to pull in flavor-specific versions of those library modules
there's probably a recipe for that, but I haven't used it, and I recall that flavors and libraries were a messy combination
I definitely don't see how you can use project properties to manage this on a per-flavor basis
though I can't rule out there being a recipe for that either
Steve T.
Yeah
Mark M.
but I'd be kinda scared of changing dependency versions on the fly without it being tied to separate build variants
as I don't know if Gradle will realize that it needs to do a full rebuild of the modules when those versions change
4:30 PM
Steve T.
I was initially thinking of hacking some sort of 'project-level' flavor
Where it will use a different file to import ext.* constants
But you would always have to change that value in the project-level gradle depending on the flavor
And it wouldn't happen automatically
Mark M.
what is the reason for having "a bunch of library modules" in the first place?
it feels like they are tightly coupled to the main app
what are you buying for having those pulled out as library modules?
as if this were all one big happy module, your dependency issue would be trivial
Steve T.
The library modules are mainly forked submodules
4:35 PM
Steve T.
And all of those will read the project-level's constants to see what version of the support library to use
Mark M.
sorry, I don't have any silver bullets for you
Steve T.
Yeah, it's ok. I appreciate your time though! Thank you!
4:50 PM
Steve T.
has left the room
4:55 PM
Mark M.
turned off guest access

← Tuesday, November 29

 

Office Hours

People in this transcript

  • Mark Murphy
  • Steve T