Assuming fooDebugCompile still isn't possible, what can be done to work
around the need for this? I'm new to Gradle, so I have no idea how to do
it, but I know the system is quite flexible, so I assume it's possible.
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
> <javascript:>> 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 <javascript:>.
>> 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.
