Actually the afterEvaluate trick is not going to work. This is because while this Configuration object is created, it's not used :\
On Mon, Mar 10, 2014 at 5:13 PM, Xavier Ducrohet <[email protected]> wrote: > You said "envTestMediaarcDebug" is a proper build flavor. It's not, it's > a build variant (ie a combination of flavor(s) and type). > > This is important because we don't support configuration object that > represent a variant. We'd like to, but there's an issue that needs to be > fixed before we can add then and it's going to take a little while. > > What's happening though is that those objects get created anyway, when > they shouldn't! > > I'm not sure if this is new due to a lot of changes we did for the library > flavor support or if it was there before. > > What's happening though is that those objects are created too late (in > after evaluate) due to the issue mentioned above. > > So you could fix it by writing > > afterEvaluate { > dependencies { > .... > } > } > > Ultimately this will be fixed, in the meantime I'm kind of leaning toward > removing them (if I can because they are created automatically when we > create the variant-specific sourcesets we introduced recently). > > > On Mon, Mar 10, 2014 at 4:34 PM, Streets Of Boston < > [email protected]> wrote: > >> No difference. I get the same error. >> >> I tried this build.gradle file. >> >> buildscript { >> repositories { >> mavenCentral() >> } >> dependencies { >> classpath 'com.android.tools.build:gradle:0.9.+' >> } >> } >> apply plugin: 'android-library' >> >> repositories { >> mavenCentral() >> } >> >> android { >> compileSdkVersion rootProject.ext.compileSdkVersion >> buildToolsVersion rootProject.ext.buildToolsVersion >> >> defaultConfig { >> minSdkVersion rootProject.ext.minSdkVersion >> targetSdkVersion rootProject.ext.targetSdkVersion >> } >> >> flavorGroups "server_environment", "oem" >> >> productFlavors { >> envTest { >> flavorGroup "server_environment" >> } >> >> envProd { >> flavorGroup "server_environment" >> } >> >> mediaarc { >> flavorGroup "oem" >> } >> >> toshiba { >> flavorGroup "oem" >> } >> } >> } >> >> dependencies { >> // compile project(':libraries:android-jenga-utils') >> >> *envTestMediaarcDebugCompile >> project(':libraries:android-jenga-utils')* >> >> compile files('libs/gson-2.2.4.jar', 'libs/mobileservices-1.0.0.jar', >> 'libs/jackson-core-asl-1.9.12.jar', 'libs/jackson-mapper-asl-1.9.12.jar', >> 'libs/simple-xml-2.7.jar') >> } >> >> >> This build.gradle file will give the DSL error. >> >> However, when i replace *envTestMediaarcDebugCompile *with just >> *envTestCompile >> *or *mediaarcCompile*, etc, the error goes away the build.gradle file >> parses/compiles OK. >> As soon as I add 'Debug' or 'Release' or* use more then one flavor or >> type combination, i get the error*. >> >> >> On Monday, March 10, 2014 2:43:43 PM UTC-4, Xavier Ducrohet wrote: >> >>> oh, wheres is your dependencies {} block compared to your android {} >>> block? >>> >>> The configuration objects are created while parsing the android {} >>> block, so your dependencies one should be after. >>> >>> >>> On Mon, Mar 10, 2014 at 11:15 AM, Streets Of Boston <[email protected] >>> > wrote: >>> >>>> I get a long list of dependencies. This is part of that list: >>>> >>>> This 'gradlew dependencies libraries:android-jenga-rest:dependencies' >>>> produces this: >>>> >>>> ... >>>> ... >>>> envTestMediaarcDebug - Published Configuration for Variant >>>> envTestMediaarcDebug >>>> \--- project :libraries:android-jenga-utils >>>> +--- com.android.support:support-v4:19.0.+ -> 19.0.1 >>>> \--- com.android.support:support-v13:19.0.+ -> 19.0.1 >>>> \--- com.android.support:support-v4:19.0.1 >>>> >>>> envTestMediaarcDebugCompile - Classpath for compiling the >>>> envTestMediaarcDebug sources. >>>> No dependencies >>>> >>>> envTestMediaarcDebugProvided - Classpath for only compiling the >>>> envTestMediaarcDebug sources. >>>> No dependencies >>>> >>>> envTestMediaarcDebugPublish - Classpath only used for publishing. >>>> No dependencies >>>> >>>> envTestMediaarcProvided - Classpath for only compiling the >>>> envTestMediaarc sources. >>>> No dependencies >>>> >>>> envTestMediaarcPublish - Classpath only used for publishing. >>>> No dependencies >>>> ... >>>> ... >>>> >>>> It looks like the list of depencies lists the >>>> envTestMediaarcDebugCompile one. However, using it in the >>>> 'dependencies' for compilation if fails with that DSL error. >>>> >>>> On Monday, March 10, 2014 1:28:13 PM UTC-4, Xavier Ducrohet wrote: >>>> >>>>> Do a "gradle dependencies" from the command line to see all the >>>>> project configurations to make sure the one you need is there. >>>>> >>>>> >>>>> On Mon, Mar 10, 2014 at 10:00 AM, Streets Of Boston < >>>>> [email protected]> wrote: >>>>> >>>>>> I tried your suggestion, but i can't get it to work. >>>>>> >>>>>> I keep getting these type of error messages when syncing the gradle >>>>>> file >>>>>> (envTest and Mediaarc are two flavors, Debug is the build type). >>>>>> >>>>>> I checked that 'envTestMediaarcDebug' is a proper build flavor. >>>>>> >>>>>> In build.gradle there is this line in the dependencies: >>>>>> >>>>>> envTestMediaarcDebugCompile project(path: >>>>>> ':libraries:android-jenga-rest', configuration: 'mediaarcDebug') >>>>>> >>>>>> When syncing the build.gradle, it gives this error: >>>>>> >>>>>> Build script error, unsupported Gradle DSL method found: >>>>>> 'envTestMediaarcDebugCompile()'! >>>>>> >>>>>> I tried with and without the 'Debug', i tried >>>>>> 'compileEnvTestMediaarcDebug' instead, (with and without the 'Debug' >>>>>> part)... >>>>>> It always give the DSL method not found error. >>>>>> >>>>>> I probably do something wrong, but I can't figure out what.... >>>>>> >>>>>> >>>>>> On Wednesday, March 5, 2014 4:04:38 PM UTC-5, Xavier Ducrohet wrote: >>>>>> >>>>>>> You could, but the dependencies are very manual for now. >>>>>>> >>>>>>> So in your apps you'd have to do something like this: >>>>>>> >>>>>>> dependencies { >>>>>>> flavor1Compile project(path: ':lib1', configuration: >>>>>>> 'flavor1Release') >>>>>>> flavor2Compile project(path: ':lib1', configuration: >>>>>>> 'flavor2Release') >>>>>>> } >>>>>>> >>>>>>> This is really not great if you have a different flavor groups, but >>>>>>> it's possible at least. >>>>>>> >>>>>>> >>>>>>> On Wed, Mar 5, 2014 at 12:12 PM, Streets Of Boston < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> Question about library build-variants with app build-variants. >>>>>>>> >>>>>>>> I have a number of apps with a number of build-variants (defined in >>>>>>>> flavorGroups and productFlavors). >>>>>>>> I have a library project supporting all these apps. >>>>>>>> >>>>>>>> The variant-sources in the apps redefine stuff (code/resources) >>>>>>>> that are originally defined/declared in the library project. >>>>>>>> These re-definitions are the same for each app, duplicated, because >>>>>>>> the library project didn't support build-variants. >>>>>>>> >>>>>>>> Now that library projects support build-variants, is there a way to >>>>>>>> tie an app's product-flavor to a library build-variant and move the >>>>>>>> variant-sources from the app-projects to the variant-sources of the >>>>>>>> library-project? >>>>>>>> >>>>>>>> Thanks! >>>>>>>> >>>>>>>> >>>>>>>> On Wednesday, March 5, 2014 2:18:27 PM UTC-5, Xavier Ducrohet wrote: >>>>>>>>> >>>>>>>>> Release notes: http://tools.android.com/tech-docs/new-build-system >>>>>>>>> >>>>>>>>> -- >>>>>>>>> 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/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 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. >>>> >>> >>> >>> >>> -- >>> 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. >> > > > > -- > Xavier Ducrohet > Android SDK Tech Lead > Google Inc. > http://developer.android.com | http://tools.android.com > > Please do not send me questions directly. Thanks! > -- 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.
