Thanks, Xavier. I had tried this before and thought I had most of the pieces but couldn't get it to work. But, I think maybe I missed doing the configurations piece correctly. Perhaps I'll give it another shot - I also was going to make you a test project for the assets issue, but deadlines apply much more pressure than these investigations. We do at least have a silly workaround we can live with for a good while and look forward to cascading variants become available in the tools.
greg On Wed, Feb 18, 2015 at 11:24 AM, Xavier Ducrohet <[email protected]> wrote: > Library do support product flavors. > > However they publish a full variant, so it'd be flavor1Debug, > flavor1Release, flavor2Debug, flavor2Release. > > It makes it complicated to have an app project and a lib project with the > same flavors and have the proper dependency. > > You'd want to write: > dependency { > compile project(':lib') > } > and have it take care of things, but it doesn't work yet (there is some > ongoing work to make it happen). > > So you end up having to do (in your app project): > > configurations { > flavor1DebugCompile > flavor1ReleaseCompile > flavor2DebugCompile > flavor2ReleaseCompile > } > > android { > // ... define flavor1, flavor2 > } > > dependencies { > flavor1DebugCompile project(path: ':lib', configuration: > 'flavor1DebugCompile') > flavor1ReleaseCompile project(path: ':lib', configuration: > 'flavor1ReleaseCompile') > flavor2DebugCompile project(path: ':lib', configuration: > 'flavor2DebugCompile') > flavor2ReleaseCompile project(path: ':lib', configuration: > 'flavor2ReleaseCompile') > } > > > A few notes: > - In your library project, on top of declaring the same flavor, you'll > want to use publishNonDefault = true to publish all variants. > > - In your app project you have to manually declare the configuration > objects first due to a timing issue. Normally as Build Types, and Product > Flavors are read from build.gradle we create matching configuration object, > allowing you do to things like 'debugCompile ....' > However, the variants, created from the build types + flavors, are > processed after the whole build.gradle file is parsed/executed. This means > that the dependencies block is processed before the variants have been > created, and before the variant-specific configuration have been created. > Since we only create them if they don't already exist, you can preemptively > create them and it'll work. > > Obviously this is not great. Pretty ugly I'd say even. And it doesn't > scale well with more flavors, or even 2+ dimensions of flavors. > > > > On Wed, Feb 18, 2015 at 10:54 AM, Artem Zinnatullin < > [email protected]> wrote: > >> You can build different types of your dependencies to binary artefacts >> and include different versions in main project using product flavored >> dependency (or buildType) >> >> For example: >> >> main_project build.gradle: >> >> android { >> productFlavors { >> flavor1 >> flavor2 >> } >> } >> >> dependencies { >> flavor1Compile 'dependencyVersionForFlavor1' >> flavor2Compile 'dependencyVersionForFlavor2' >> } >> >> But as I know library projects don't support product flavors >> >> On Wednesday, February 18, 2015 at 9:02:25 PM UTC+3, Greg Macdonald wrote: >>> >>> Thanks, Artem >>> >>> That makes sense and surely it is a good use case. >>> >>> In our case, we need all modules to be built with the same build >>> variant. It makes more sense to me that dependencies included as pre-built >>> artifacts will come in as release built modules, but for sub-projects that >>> are built as part of building the app, it makes sense that this is code >>> also under development and when I want the app to be built with a >>> particular build target and flavor, I should have the option of this being >>> applied to those modules also. The fact that it does not work this way by >>> default is odd to me. I'm pretty sure that other IDE's I've used for >>> different compiled languages all work this way. >>> >>> thanks, >>> greg >>> >>> On Wed, Feb 18, 2015 at 8:39 AM, Artem Zinnatullin < >>> [email protected]> wrote: >>> >>>> Greg, I am really sorry for my first reply to your post, please accept >>>> my apologies :( >>>> >>>> It's design of Gradle: build of one project should not affect build >>>> state of other projects involved in build process. >>>> >>>> Library subproject should not know about build params of main project, >>>> because you should be able to replace it as already built artefact. >>>> >>>> But you can try to share some pieces of Gradle configuration between >>>> projects, for example you can declare some variables in root build.gradle >>>> like this: project.ext { someVar } >>>> and then read it in subproject: project.someVar, it can help with >>>> flavor specific build config fields >>>> >>>> On Wednesday, February 11, 2015 at 9:22:56 PM UTC+3, Greg Macdonald >>>> wrote: >>>>> >>>>> Kevin, what do your numbers 1-5 relate to? esp. 3 & 4 >>>>> >>>>> >>...can't necessarily flow the variants up to the libraries... >>>>> >>>>> No, you cannot at all affect the build of sub-projects. Everything but >>>>> your main app project are built as release. So, for example, referencing >>>>> BuildConfig.DEBUG from code gives a different answer from the app project >>>>> than from a subordinate library project. >>>>> >>>>> On Wed, Feb 11, 2015 at 6:11 AM, Kevin Schultz <[email protected]> >>>>> wrote: >>>>> >>>>>> I don't understand these points at all. >>>>>> >>>>>> 1) You can maintain Eclipse & AS support at the same time. Back when >>>>>> AS was actually unstable and Eclipse was actually more useful, I >>>>>> maintained >>>>>> both ant & gradle support in our project so that our team could use >>>>>> either. >>>>>> Keep the source structure as Eclipse expects it, and change the >>>>>> sourceSets >>>>>> in the gradle config to match. There are examples of this online. >>>>>> >>>>>> Of course, you will quickly find that all the power of Gradle is lost >>>>>> if you handcuff yourself to only features that also work under Ant. I >>>>>> made >>>>>> it such that you could build a debug build with Ant, but if you wanted >>>>>> the >>>>>> other build types, you had to use Gradle. That allowed the team to >>>>>> continue >>>>>> using the tools they wanted while we experimented with AS. Note that this >>>>>> was fall of 2013. Our team of 5 Android developers switched relatively >>>>>> soon >>>>>> their after, and we haven't looked back. I personally use the canary >>>>>> channel of AS, and I may have lost 2 business days to tools problems, out >>>>>> of hundreds and hundreds of days. The productivity gain has more than >>>>>> made >>>>>> up for it. New features may have issues, but generally speaking we're >>>>>> talking about issues with feature that didn't exist in Eclipse + ADT >>>>>> anyway, and that doesn't stop you from getting your work done as you had >>>>>> before. >>>>>> >>>>>> There are very narrow use cases where AS doesn't have the support you >>>>>> need, but outside of native code the argument that "Android Studio is not >>>>>> ready for prime time" doesn't hold any water. >>>>>> >>>>>> 2) Most libraries will work - with the exception of AAR - in Eclipse. >>>>>> However, I can tell you most of the people writing libs are using the >>>>>> modern tools. >>>>>> >>>>>> 3) Yes >>>>>> >>>>>> 4) ? >>>>>> >>>>>> 5) Module support under AS is way better than under Eclipse. It's >>>>>> trivial to add Java or Android library modules to the project and it >>>>>> works >>>>>> quite well. I have split my app into a few different modules and I'm >>>>>> quite >>>>>> happy with it. You can't necessarily flow the variants up to the >>>>>> libraries, >>>>>> but there wasn't even a mechanism for something like build variants in >>>>>> Ant, >>>>>> so I'm not sure I see how that is a knock on Gradle. >>>>>> >>>>>> >>>>>> On Wednesday, February 11, 2015 at 1:10:34 AM UTC-5, Greg Macdonald >>>>>> wrote: >>>>>>> >>>>>>> Thanks, Kiran. We've a long term Android guy on our team who is >>>>>>> experienced with eclipse & ant and our project is yet small; but, yes, >>>>>>> I'm >>>>>>> concerned about switching and I sure don't want to get stuck in an >>>>>>> old-tools world once AS is working well enough and moving forward. >>>>>>> >>>>>>> So, what I hear from you in balance is: >>>>>>> - if one goes back, we all go together >>>>>>> - 3rd party libs may not be maintaining support for eclipse-centered >>>>>>> tools >>>>>>> - ADT support for eclipse may wane (yea, in keeping with comments by >>>>>>> ADT lead) >>>>>>> - Binary repos (I'm thinking this isn't a big deal, isn't maven >>>>>>> under jcenter anyway?) >>>>>>> >>>>>>> BTW, we are also considering turning the project into one monolithic >>>>>>> project for now and breaking it up into sub-projects again when the >>>>>>> tools >>>>>>> support it better, but it's hard to maintain discipline around >>>>>>> hierarchical >>>>>>> order and separation in such a world. Alas and alack. >>>>>>> >>>>>>> Thanks again, Kiran >>>>>>> >>>>>>> >>>>>>> On Tue, Feb 10, 2015 at 8:17 PM, Kiran Rao <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> @Greg, >>>>>>>> >>>>>>>> I think reverting is more difficult because you will have to do >>>>>>>> everything manually. While there is a migration path (and tooling >>>>>>>> support) >>>>>>>> for "converting" your project from Eclipse to Android Studio, there is >>>>>>>> no >>>>>>>> support for the opposite. >>>>>>>> >>>>>>>> You will find documentation on how you can make some adjustments to >>>>>>>> the sourceSets in build.gradle such that the same project can be >>>>>>>> worked on >>>>>>>> from both AS and Eclipse + ADT - however in practice this doesn't work >>>>>>>> well >>>>>>>> (and I have tried this on a team of only two developers!) >>>>>>>> >>>>>>>> I have also found that of late, most open source libraries use the >>>>>>>> AS/Gradle structure. You could of course grab the dependencies as >>>>>>>> binaries, >>>>>>>> or better, use Maven with your Eclipse/ADT setup. But then again, >>>>>>>> several >>>>>>>> libraries are distributed as AARs and last time I checked, Eclipse/ADT >>>>>>>> had >>>>>>>> trouble consuming AARs (at least Eclipse/ADT without Maven plugins >>>>>>>> did). >>>>>>>> >>>>>>>> What I'm trying to arrive at is that reverting to Eclipse might >>>>>>>> imply reduced support going forward - both from the Tools team as well >>>>>>>> as >>>>>>>> from the community. >>>>>>>> >>>>>>>> On Wednesday, 11 February 2015 06:56:18 UTC+5:30, Greg Macdonald >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> OK, I should add to 'factual', input that is useful. I'm really >>>>>>>>> not interested in religious wars or 'tude. >>>>>>>>> >>>>>>>>> On Tue, Feb 10, 2015 at 5:20 PM, Artem Zinnatullin < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >>>>>>>>>> nano + javac is better choice for your team. >>>>>>>>>> >>>>>>>>>> For what reason you want to use flavors in not app modules? Seems >>>>>>>>>> to be architect/design problem. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> P.S. >>>>>>>>>> >>>>>>>>>> Gradle is stable, working build tool, Android Gradle Plugin and >>>>>>>>>> Android Studio are stable too, just fix dependecies versions. I >>>>>>>>>> started to >>>>>>>>>> use them from first public releases and I even changed 3 companies >>>>>>>>>> after >>>>>>>>>> this. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I just can't understand why people use Ant in 2015, okay, you >>>>>>>>>> don't want to use Gradle, but there is Maven. It's just >>>>>>>>>> unwillingness to >>>>>>>>>> learn new things, and in my opinion — it's unprofessional. >>>>>>>>>> >>>>>>>>>> Learning new should not be hard, it should be fun and useful for >>>>>>>>>> yourself. >>>>>>>>>> >>>>>>>>>> Just start with small personal project with Android Studio and >>>>>>>>>> Gradle, when you'll feel comfortable with them, try to switch work >>>>>>>>>> project >>>>>>>>>> to Gradle + AS. >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> 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. >>>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>> 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. >>>>>>>> >>>>>>> >>>>>>> -- >>>>>> 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. >>>>>> >>>>> >>>>> -- >>>> 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. >>>> >>> >>> -- >> 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. >> > > > > -- > 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 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. > -- 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.
