Android build variants and Gradle configurations

[Roman Mazur]

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?

[Luke Daley]

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

[Roman Mazur]

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?

[Xavier Ducrohet]

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.

--
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!

[Justin Hong]

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

[Justin Hong]

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:

[Xavier Ducrohet]

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

}

For more options, visit https://groups.google.com/d/optout.

[Justin K Hong]

Awesome!  That worked beautifully.  Thanks Xavier.

You received this message because you are subscribed to a topic in the Google Groups "adt-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/adt-dev/E2H_rNyO6-o/unsubscribe.
To unsubscribe from this group and all its topics, send an email to adt-dev+u...@googlegroups.com.

[Marcus Smith]

Is this available in versions lower than 2.2.1 of Gradle?

[Xavier Ducrohet]

This should work in version 1.0 of the plugin but it requires gradle 2.2+