> > Why wouldn't you just extract an interface with different implementations?
Are you implying that the different implementations would live in the packages that correspond to differing product flavors? On Friday, August 16, 2013 10:35:57 AM UTC-7, Jake Wharton wrote: > > Replacing sources seems extremely prone to silent and difficult to track > down problems. The contract of the replaced source is only implicitly based > on the original (though enforced at compile-time at the very least). > > Why wouldn't you just extract an interface with different implementations? > > > --- > Jake Wharton > http://about.me/jakewharton > > > On Wed, Aug 14, 2013 at 11:17 PM, Kevin Gorham <[email protected] > <javascript:>> wrote: > >> We encountered this exact use-case at work today. Our apps are >> sports-related and we are leveraging flavors and flavor groups to vastly >> cut down on unnecessary projects with lots of elements in common. Each >> school can be a different flavor, along with "paid" and "free" groups. >> >> Personally, I think it's going to be a fairly common case with users who >> make meaningful use of buildVariants. Eventually, variations will arise >> that can't be fully covered by styles/themes/etc. Unfortunately, most >> solutions to this are either "hacky" or involve bloating all variants with >> code that only applies to a few (admittedly, the solution proposed here >> feels like a hack). Having a structured & consistent way of managing this >> would be ideal. >> >> That prompted me to join this group and start looking into how to >> contribute to ADT. I imagine the core team has more important things to >> work on so it would be nice to lend a hand with making this less clumsy. >> Having the gradle plugin allow for this in a "declarative" way (i.e. >> replaceSources=true), feels more like the "right" approach. >> >> Anybody agree? >> >> - Kevin >> >> >> On Tuesday, August 13, 2013 6:20:10 AM UTC-6, Thomas Bruyelle wrote: >>> >>> I want to build an "admin" version of my app, but not with the usage of >>> product flavors, because I don't want variants like adminDebug or >>> adminRelease. >>> So I created a new buildtype "admin" which extends the "debug" one, and >>> created a new folder "admin" in my src folder. >>> >>> My idea is to redefine some classes and layouts in the admin folder, in >>> order to add special capabilities. But when I launch "gradle >>> assembleAdmin", I get an error "duplicate classes". >>> >>> It seems the build types merge works well for resources, but not for >>> java source files, am I wrong ? >>> If true, can someone give me a tip to override source files with build >>> types ? >>> >>> Thx in advance >>> >> -- >> 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] <javascript:>. >> 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/d/optout.
