Thanks Scott, I know I can run the specific task (it was my second bullet point). And I see your point in combination explosion. I actually first considered these settings differences as flavors, but I noticed that it would be just a small bunch of xml files on top of a lot of common code, so they were orthogonal to the flavors, also because they "could" be used across different flavors.
However, as you said, I am creating complexity and I am not going to test all of them because such settings don't require tests in my opinion. As a simplified example, flavor1 might be assembled: 1 - with autoUpdate setting visible and disabled (dev) 2 - with autoUpdate setting visible and enabled (demo) 3 - with autoUpdate setting invisible and enabled (customer) In this case I planned to use debug, debugDemo, release buildTypes. But debugDemo does not apply to Flavor2. Would you have any pointer to achieve this with runtime configuration? On Fri, Feb 28, 2014 at 6:29 PM, Scott Barta <[email protected]> wrote: > The use case that was in mind when developing the "build type" concept was > debug vs. release: debug may have extra runtime checking code, it won't use > Proguard, it will be debuggable in the IDE, and it will be signed with the > debug key, but it's usually functionally equivalent to the other build > types (e.g. Release). > > With flavors, the intent was different versions of the app which are > functionally different even in release versions: free vs. paid, perhaps > something like an enterprise version vs. consumer version, etc. > > Having said that, you can of course do what makes sense to you, and in > practice build types and flavors are similar concepts and allow similar > types of configuration. But if you find yourself wanting to have > sub-flavors inside flavors, it might help to take a step back and look at > what you're doing to see if there's an easier way. You talk about a > "predefined set of preferences" that differ in some of your sub-flavors; > perhaps you could differentiate these via runtime configuration instead of > making separate variants. If you have too many build variants, it will make > your development and testing really tough as the number of combinations > explodes. You'll help yourself out by restricting flavors to cases where > the code or resources really need to be different, and making the decision > at runtime just really doesn't work. > > When you're running the Gradle commands from the command line, you can > specify which variant they act on. Instead of: > > ./gradlew assemble > > you can use: > > ./gradlew assembleFlavor1Debug > > etc. You can see the possibilities via: > > ./gradlew tasks > > > On Fri, Feb 28, 2014 at 9:14 AM, Diego Costantini < > [email protected]> wrote: > >> The question seems very generic but I have a concrete (corner?) case in >> mind. >> >> I have 3 flavors and I test them in Jenkins with some default settings >> which are good for us developers. >> However, when I want to release them, I want different preferences for >> the user, sometimes even more than one kind per flavor. >> For this, I created different buildTypes, let's say for example that I >> want Flavor1-ReleaseFlavor1 where I use a predefined set of preferences. >> In this case, the build type ReleaseFlavor1 is specific to Flavor1, and >> when generating the tasks, I would have many meaningless combinations like >> Flavor2-ReleaseFlavor1. >> >> Now, related to the topic question: >> - is it ok and I should just ignore those builds when running assemble? >> -> big waste of time waiting for the extra meaningless builds >> - should I avoid running assemble? -> I lose a quick way to build all the >> variants I might need >> - is there a way to filter out undesired combinations? -> this would make >> sense >> >> -- >> You received this message because you are subscribed to the Google Groups >> "adt-dev" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/groups/opt_out. >> > > -- > You received this message because you are subscribed to a topic in the > Google Groups "adt-dev" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/adt-dev/Z26wxPc7OKs/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. > -- You received this message because you are subscribed to the Google Groups "adt-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
