This should work in version 1.0 of the plugin but it requires gradle 2.2+
On Thu, Feb 19, 2015 at 11:40 AM, Marcus Smith <mar...@laundrapp.com> wrote:
> Is this available in versions lower than 2.2.1 of Gradle?
>
> On Monday, January 5, 2015 at 7:15:37 PM UTC, Xavier Ducrohet wrote:
>>
>> 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 <jkai...@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+u...@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.
>
--
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.
