JakeWharton / u2020

A sample Android app which showcases advanced usage of Dagger among other open source libraries.
https://www.youtube.com/watch?v=0XHx9jtxIxU
Apache License 2.0
5.68k stars 930 forks source link

Proposed PR: extract dependencies definitions in dependencies.gradle #200

Closed jmfayard closed 9 years ago

jmfayard commented 9 years ago

Hello, for our projects, I started to apply a pattern for the build system to extract the definitions in a separate dependencies.gradle file

// apply from: '../dependencies.gradle'
ext {
    androidoptions = [
            buildToolsVersion : "23.0.0",
            minSdkVersion : 15,
            targetSdkVersion : 23,
            compileSdkVersion : 23,
    ]
    libs = [
            butterknife:            "com.jakewharton:butterknife:7.0.1",
            timber:                  "com.jakewharton.timber:timber:3.0.2",
            retrofit:               "com.squareup.retrofit:retrofit:1.9.0",
            // all the others
    ]
}

Then app/build.gradle looks like

apply plugin: 'com.android.application'
apply plugin: 'com.neenbedankt.android-apt'

/** The values of the dependencies are defined in this file **/
apply from: '../dependencies.gradle'

android {

    compileSdkVersion androidoptions.compileSdkVersion
    buildToolsVersion androidoptions.buildToolsVersion
    defaultConfig {
        minSdkVersion    androidoptions.minSdkVersion
        targetSdkVersion androidoptions.targetSdkVersion
        versionName "0.1"
        applicationId "com.example"
    }
}
dependencies {
    compile libs.butterknife
    compile libs.retrofit
}
/** everything else **/

I find it makes it less error-prone to write gradle builds and to compare libraries versions accross different projects.

Would you like to see a pull request along those lines?

f2prateek commented 9 years ago

I think that this pattern doesn't really help u2020 since it contains only one module. There simply isn't a need to share library versions in multiple places.

mattprecious commented 9 years ago

Yeah, we do this internally as well, but we have multiple modules. I don't think it makes sense in u2020 as it adds an unnecessary layer of abstraction.

JakeWharton commented 9 years ago

Agreed. We do the same in our projects (including other open source ones). This repo has only a single module so I don't think it would be useful. It's definitely the right thing in larger projects, though.