fooDebugCompile works but you have to declare it first. This is a timing
issue that we ran into, though I'm hopeful this can be removed in the
future.
configurations {
fooDebugCompile
}
android {
productFlavors {
foo {}
}
}
dependencies {
fooDebugCompile ...
}
On Sun, Dec 28, 2014 at 8:52 PM, Justin Hong <jkaih...@gmail.com> wrote:
> Xavier,
>
> Any word on fooDebugCompile coming into being? I tried recently with the
> 2.2.1 Gradle version and found that I couldn't do it.
>
> Thanks,
>
>
> - Justin
>
> On Saturday, January 18, 2014 12:47:13 PM UTC-6, Xavier Ducrohet wrote:
>>
>> Luke is confident, because he's one of the core Gradle developer :)
>>
>> My team is working with the Gradle team to make the flavor support in
>> library. I'm not sure how it's going to look like at the publication level.
>> Obviously, Gradle will need to be able to support publishing different
>> variants. It's not something that can be mapped easily to existing
>> dependency management (for maven we'd have to allow making each variant a
>> different artifact) but internally (when doing inter-project dependencies)
>> we can leverage a more complex system.
>>
>> While I'm not sure yet how it'll be done exactly internally, here's what
>> I want it to look like for a user.
>>
>> dependencies {
>> compile projet(':mylib')
>> }
>>
>> that's it. If both publisher and consumer declares the same variant,
>> nothing else needs to happen. Variant FooDebug of the project should
>> automatically consume variant FooDebug of the library.
>>
>> Now if the library and app variants don't match, we can provide a way
>> through the DSL to provide a custom mapping. Simple mapping like the
>> library only having debug/release can be easily mapped (any debug variant
>> of the app use the debug library). In other case you'll simple provide a
>> custom mapping.
>>
>> If you publish the library to an artifact repository you'll probably have
>> to go through different artifacts, and do
>>
>> dependencies {
>> fooDebugCompile 'com.myapp:mylib-foo-debug:1.0'
>> barDebugCompile 'com.myapp:mylib-bar-debug:1.0'
>> }
>>
>> Note that currently fooDebugCompile doesn't exist. We only have
>> "fooCompile" or "debugCompile", but we are planning to add this.
>>
>>
>>
>> On Sat, Jan 18, 2014 at 6:46 AM, Roman Mazur <mazur...@gmail.com> wrote:
>>
>>> Well, you sound rather confident :)
>>> Yet, as far as I know Android library plugin will soon make it possible
>>> to define flavours.
>>> How will we specify dependency on some library flavour?
>>> Will library variant produce a separate configuration which will be
>>> specified in a usual way in dependency description?
>>>
>>> On Saturday, 18 January 2014 14:06:03 UTC+2, Luke Daley wrote:
>>>
>>>>
>>>> On 18 Jan 2014, at 10:36 am, Roman Mazur <mazur...@gmail.com> wrote:
>>>>
>>>> > I wonder what are the dev team plans as for further development of
>>>> build variants.
>>>> > Currently they are completely unrelated to Gradle configurations (I
>>>> mean dependency configurations), yet I have a feeling these are pretty
>>>> similar concepts.
>>>> > So don't you plan to make them be the same thing?
>>>>
>>>> I can't speak on behalf of the Android team, but I can give some
>>>> context on this from the Gradle side.
>>>>
>>>> Variants and configurations aren't the same thing. Configurations in
>>>> their current form, at an abstract level, represent a particular input
>>>> (dependencies) / output (artifacts) channel for the project. There's a
>>>> relationship between variants in so far that variants may be backed by one
>>>> or more configurations, which they actually already are in the current
>>>> Android plugin implementation. This is a more natural arrangement. A
>>>> variant is much more than inputs/outputs so it makes sense to conceptually
>>>> make a configuration part of its composition (i.e. has-a), opposed to
>>>> trying to be a configuration (i.e. is-a).
>>>>
>>>> Moreover, the best Gradle plugins use _concrete_ modelling. The Android
>>>> plugin does this well (i.e. it models the project the way developers think
>>>> of it, not as the infrastructure has to think of it). Gradle configurations
>>>> are very abstract and don't represent real things. Using such constructs at
>>>> the modelling level always leads to convolution and bad usability.
>>>>
>>>> In short, I don't think there is anything to gain in trying to do what
>>>> you are proposing and there is a lot to lose.
>>>>
>>>> --
>>>> Luke Daley
>>>> Principal Engineer, Gradleware
>>>> http://gradleware.com
>>>>
>>>> --
>>> 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 adt-dev+u...@googlegroups.com.
>>> 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 adt-dev+unsubscr...@googlegroups.com.
> 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 adt-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
