In such case, I'll stop bothering and I will filter out when it comes. In the meanwhile, thanks Xavier and thanks Scott :)
Sent from my Nexus 4 On Feb 28, 2014 7:28 PM, "Xavier Ducrohet" <[email protected]> wrote: > The next version of the plugin will have support for filtering out > combination that don't make sense (in your case flavor2 + debugDemo) > > > On Fri, Feb 28, 2014 at 9:43 AM, Diego Costantini < > [email protected]> wrote: > >> 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. >> > > > > -- > Xavier Ducrohet > Android SDK Tech Lead > Google Inc. > http://developer.android.com | http://tools.android.com > > Please do not send me questions directly. Thanks! > > -- > 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.
