Gradle 3.0 Dependency Configuration
As Google rolled out Android Studio 3.0 Stable version few days ago, you may be aware of the new improved dependency configuration of Gradle 3.0. It has a drastic change from the previous versions. From the first time we started using Gradle, we were used to add dependencies by writing
compile 'com.library.package:module:X.Y.Z' Google decided to change this and break it into two types of declarations namely
Why these changes? and how will they change the way we add dependencies? Let us inspect.
As Android Developer, we always compained about the build time gradle takes didn’t we? and the build time used to gradually increase as we add more dependencies to the gradle. The reason is quite simple, there are more dependencies to compile, so there would be more time to build. But the problem was somewhere else.
Think of a plugin that internally uses another plugin/dependency such as my plugin for runtime permisions, as you add
compile ‘com.rivuchk.mpermissionhandler:permissionmanager:0.2’ to your dependency, it's own dependency to Android Support Libraries V4 is automatically added (or should I say leaked?) to your project. That should not happen right? Google thought the same. But changing this behavior of transitive dependency completely is also not possible, sometimes developers want that transitive dependency for few selected cases, so the Android Studio and Gradle team at Google came up with
implementation and deprecated
So, we got the answer of our first question (the Why). Let us now find the answer of our second question (the How).
As per the definition of
implementation, it will let Gradle know that the module does not want to leak the dependency to other modules at compile time. That is, the dependency is available to other modules only at runtime. Thus, no transitive dependencies. Confused? Just remove the dependency to Android Support Libraries V4 and keep implementation on any library that has dependencies to them, you'll no longer use Android Support Libraries V4 withput adding seperate dependency on them. by using
implementation instead of
compile, you can see the build time drastically reduce in your projects
api works completely same as
compile with transitive dependencies, then why deprecating
compile and introducing
api? Just to break your habit, so that you would not use
compile accidentally when you don't need any transitive dependencies, the warning message of deprecation would remind you to use
api if you want transitive dependencies.
This was a quite short blog on new Gradle 3.0 Build Configurations. Hope you enjoyed this blog. Feel free to comment below if you have any concerns/feedback/queries.
For further reading on new gradle configurations you can visit — https://developer.android.com/studio/build/gradle-plugin-3-0-0-migration.html#new_configurations.
My book on Reactive Programming in Kotlin is now on amazon — https://www.amazon.com/Reactive-Programming-Kotlin-Rivu-Chakraborty/dp/1788473027/ or you can also pre-order at Packt — https://www.packtpub.com/application-development/reactive-programming-kotlin.
Originally published at Rivu Chakraborty.