Gradle: pros/cons adding dependencies

Question

What are some pros/cons adding dependencies in build.gradle, instead of adding them as dependent libraries?

dependencies {
    compile project(':library')
    ...
    compile 'com.stackoverflow.android:some-great-library:1.0'
    ...
}

While working on Android projects, I've frequently come across with great libraries with the exact solution I've been looking for. However, as what I need is only a fraction of what those particular libraries have to offer, I'm worried if adding them as Gradle dependencies is an overkill.

---

Per @CommonsWare's comment, I have more specific questions.

Does adding dependencies:

1. slow down compilation time at a noticeable rate?

2. increase the size of release-apk and debug-apk, as much as the size of the added dependency?

Answer 1

In Gradle dependencies are grouped into configurations as dependency configurations.External dependency is a dependency on some files built outside the current build, and stored in a repository of some kind, such as Maven central, or a corporate Maven or Ivy repository, or a directory in the local file system.

Dependency types:

External module dependency:

A dependency on an external module in some repository.

Project dependency:

A dependency on another project in the same build.

File dependency:

A dependency on a set of files on the local filesystem.

Client module dependency:

A dependency on an external module, where the artifacts are located in some repository but the module meta-data is specified by the local build. You use this kind of dependency when you want to override the meta-data for the module.

Gradle API dependency:

A dependency on the API of the current Gradle version. You use this kind of dependency when you are developing custom Gradle plugins and task types.

Local Groovy dependency:

A dependency on the Groovy version used by the current Gradle version. You use this kind of dependency when you are developing custom Gradle plugins and task types.

Pros adding dependencies:

• In Gradle, you simply declare the “names” of your dependencies, and other layers determine where to get those dependencies from.

• Code Change possible in SubProject.

• Clear direct Dependency inclusive the Version of the used Library
  Clear indirect Dependencies managed (ie. the used Library use another Library - POM Files){from User Robert Halter).

• online availablity dependent

• The require sdk library is already synced with the project for the compilations.

Cons:

As such,it has got no cons but at the initial stage while adding dependencies we have to sync it which takes a bit time than simply dragging & dropping the jar file.

Slow down compilation time at a noticeable rate?

No,because the libraries are compiled only at the time of syncing.

Increase the size of release-apk and debug-apk, as much as the size of the added dependency?

No but practically yes because it only takes the size of the build file(binary size) which hardly increaces the size in bytes or kb which is hardly traceable.

So finally adding them as Gradle dependencies is an overkill when we only need to use a fraction of a particular library?

Definately,there might be a situation like in your case to use only a subset of a library.So in that case enabling ProGuard optimizes perform analysis at the bytecode level, inside and across methods to help make your app smaller and run faster without an overkill.

Answer 2

The concern mostly about your android app size. Many of methods or classes may raise up the 64k limit on the dex file and mostly require multi-dex or jumbo mode enabling. That may creates you some compatibility issue if you have very out-dated customers.

Sometime you may want to work around it by only extracting out the classes that you needed, but it is not an easy job sometime.

If you have proguard enabled, the classes that is not being used can be systematically removed.

Answer 3

Copying code of third-party library to your project causes some problems with supporting that project What if you will need to use that library of newer version? If you'll add it as dependency then all you'll need is to change version number in build system config

Answer 4

What are pros/cons adding dependencies from a Subproject in a Gradle Build Project?

dependencies {
    compile project(':library')
}

Pros

• Change of Code in the :library Subproject is possible

Cons

• Manage by yourself the Version of the :library Subproject

What are pros/cons adding dependencies from a versioned dependent library a in Gradle Build Project?

dependencies {
    compile 'com.stackoverflow.android:some-great-library:1.0'
}

Pros

• Clear direct Dependency inclusive the Version of the used Library
• Clear indirect Dependencies managed (ie. the used Library use another Library - POM Files)
• A other Person/Group manage the Functionality of the Library - you can focus on your own Code.

Cons

• None

Does adding dependencies as :library Subproject slow down compilation time at a noticeable rate?

• Yes, they must compiled too, because they are in Source Code in your Subproject
• Gradle optimze builtime with input / output definition of a task. See UP-TO-DATE markers while building.

Does adding dependencies as versioned dependent library slow down compilation time at a noticeable rate?

• No, beacause the Libraries (.jar) are already compiled.

Does adding dependencies increase the size of release-apk and debug-apk, as much as the size of the added dependency?

• The apk Size increase the binary Size (.jar = Zipped .class Files) of the added dependency.
• (If you have proguard enabled, the classes that is not being used can be systematically removed - from User phdfong)

Answer 5

Whether to add a third-party library as dependency

You declare a dependency to a third-party library when your program uses some code in this library at compilation time or at runtime. That means that third-party code must be reachable when your program is run, so it is packed with your program. So, application size increases and this is undesired, because many users do not like huge applications. Also this is ridiculous, when your program is small and third-party library is huge.

Whether to add a third-party library as module

I've never done that, but if I understood it right, it is the same as copying library inside your project, so you could modify it. If you use releases, there will be no compilation-time difference with remote dependency compilation. Everything is same as in previous paragraph, but in addition you are free to modify the code (if third-party library license allowes it).

Whether to add extract only the code you need

This is the best solution to use, if you need just few methods from a library and it is not difficult to extract them (again, assuming that license allows to do this). On the other hand, if you use some solid third-party functionality and want to extract and modify it in your project, you can face maintenance problems in future (if you'll decide to migrate to new version).

Does adding dependencies: slow down compilation time at a noticeable rate?

With right Gradle tuning (working as daemon in background, using parallel processing) you won't see any dramatic changes in a typical project.

Does adding dependencies: increase the size of release-apk and debug-apk, as much as the size of the added dependency?

Dependency jar are sent to dex for bytecode conversion as well as your project code. This is not a 1:1 conversion in terms of size, so the answer is no. Also ProGuard has some tricks for jar size minimization and Maven has a plugin for packing all the dependent jars in one, so they all could be obfuscated.

Answer 6

I think this question isn't very dependent on Gradle but more generally by the use of "dependencies-management tools".

Surely there are situations where we need only a subset of a library. In these situations, having to import the entire dependency may not be the best solution.

How much is it "overkill"? Obviously it depends on the size of your project. It's up to you to evaluate how much "overkill" a dependency can be: for example if you need only a simple function and you are importing a library of 3MB, probably yes, is a bit 'overkill!

In addition you have to consider that usually "big" libraries are divided into modules and thus you can only import the module you need. In the case of Android, as @phdfond said, you can use ProGuard to remove unused classes at build time, or you can exclude them manually with Gradle:

//...      
sourceSets {
         main {
             java {
                 exclude '**/IDontWantThisClass.java'
             }
         }

But IMHO this situation is not very common and you can have a lot of advantages by using Gradle or another "dependencies management tool" (note that in Gradle, Maven, ecc ... the dependencies management is only one of their functionalities).

For example if you are using Gradle at a glance you know your dependencies and you can easily add/remove them or just change a number to update their version. Have you ever think that your project can depends by libs B and C, and both B and C can depends on two different versions of a lib D? Well Gradle can also help you situations like this one. I can't continue here because i would be off-topic, but you can find a lot of informations about this tools.

Finally I think that the most important "CONS" of "dependencies-management tools" is the initial learn and setup time. If you never used a tool like Gradle surely the first times will take more time than to drag and drop a jar, so I strongly encourage you to use Gradle in your projects, unless it is a "toy-project".

Answer 7

I'd say they are fundamentally different things.

1. Gradle subproject

dependencies {
  compile project(':foobarlib')
}

In this first case, you are depending on an Android subproject, part of the gradle project you are working on. You may also call this type of dependency a module, as Intellij does.

If you wish to make a change, you may do so and all it takes for that change to be visible is a gradle compilation of the root gradle project.

2. Android library project

dependencies {
  compile 'com.example:foobarlib:2.1.0'
}

In this second case, what you are depending on is an artefact (i.e. an archive in the JAR or AAR format), not a project. This is essentially a black box to your gradle project. All gradle knows is that it contains compiled classes (and resources in case of an AAR) that your project needs.

If you wish to make a change in the library, first you need to locate its corresponding project to edit its sources, compile the project and publish the new artefact to either a local o remote maven repository. Finally, for your project to see the changes made in this other project, you will have to update the version number declared in the dependency so that gradle knows that it will have to bring the newly published artefact.

Which one is better?

It depends, of course. Just think of whether or not the library has a sense for it to be on its own or if it's actually just a module of your app. As you saw, the second approach adds too much overhead if you are just working on a module of your app and it also makes no sense to version and distribute those changes without the rest of the app.

Answer 8

Gradle dependency is an overkill

Well it is if you are using some stable library or you are satisfied with the current library features. Also when the library has dependencies for backward porting or has a set of features or say classes which you simply don't need.

The solution will be take what you need from the library, (only when you are sure that it will suffice your requirements)

And it's not

If you want automatic updates and fixes to your library, ease of integration. Many of the libraries are made and maintained everyday, So may be the APK size doesn't matters that much to us, as much the library updates, So gradle imports are good there.

Concerns on APK size

A gradle dependency may have lot of unrelated stuff, backward support which your app doesn't require, which in the end increase the application size, also will result in slow compilation too.

So, If the library has a single class or fewer class you can directly add it to your application in some package. A good example will be the Google IO app, where some libraries are their in a different package.

You can also control what goes to debug or release apk, for debug dependencies use debugCompile, for test dependencies use testCompile

Adding the library as module dependency

Adding as library module will speed up the build process by the download time required for fetching the dependency, which you can easily achieve by Enable offline sync for Gradle in Android studio.

Also library modules are the way, if you have developed some private library and you use it throughout your own projects, if that is not the case you will have the library published and maintained on maven central and will be easier to integrate to your own set of projects through gradle.

Answer 9

1. slow down compilation time at a noticeable rate?

Short Answer: Yes.

Long Answer: We are currently using Gradle in our project and there is a CONSIDERABLE difference in the complitaion time that i have experienced. This is especially true if you have a project that has multiple-module dependencies. Also not to mention the fact that if you are keep adding a lot of dependencies only to use a bunch of classes from each one of them you eventually run into the very famous:

Too many references: 66539 error; max is 65536.

I have experienced this a bunch of times(gradle and maven) myself when using libraries which are resource-intensive(play-services for example).

2. `increase the size of release-apk and debug-apk, as much as the size of the added dependency?`

Definately does. Not so much for the release-apk since you can optimize proguard to whatever extend you want. In case of debug-apk, i have seen size variations of upto 5-6 MB.

Just my 2 cents. Hope this helps.