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