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 envTestMediaarcDebugCompil
>>> e 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!

-- 
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.

Reply via email to