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 <[email protected]> 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 <[email protected]> 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 [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/groups/opt_out.
