Git repos as Gradle dependencies
It is not an uncommon desire to split your codebase into reusable libraries (git repositories). Let’s review what options we have if we want to include external code into a Gradle project.
Git submodulesAn obvious choice can be git submodules. Creating a git submodule is easy:
git submodule add {url} {name}
And then you need to manually download submodules with
git submodule update --init --recursive
Looks simple, but using git submodules can quickly become painful. GitHub does not recommend to use it in most cases, because:
If you have a simple use case and want to include an external repository that will change rarely then this option can be good enough.
Binary artifactsThe most popular option is to publish shared code as binary ( Open source libs can be distributed with one of a few free public Maven repositories like Sonatype, Bintray, etc. But if you want to distribute privately within a company then you’ll need to maintain your own private Maven repository (e.g. Artifactory), pay for external services (e.g. Bintray), or try to use git repo as a Maven repository. If you store your code on GitHub then you can use GitHub Packages, it is also available for private repositories, the main downside of this service is a storage limit. Once published it becomes very easy to use the library by adding it as a regular Gradle dependency. But this approach has a few important limitations:
Overall this is a great option for public libraries, for big companies, or when no frequent changes are expected. In other cases it may become frustrating to make changes to the libraries and maintain the necessary infrastructure.
JitPackJitPack is a nice service that builds git repos on their servers on your behalf, it supports lots of git hostings (GitHub, Bitbucket, Gitlab), supports private repositories and even supports Android flavors. The usage is simple:
Overall it’s an interesting combo of a regular (“manual”) Maven repository and CI server. It is indeed much easier to set up a library and release new versions with JitPack. Though it still has some of drawbacks of a regular binary distribution:
Gradle source dependenciesSource dependencies feature was introduced back in Gradle 4.x, it works by including a regular dependency and specifying how to get it from external git repo, in
Gradle will download the sources from the (public) git repository and will try to build a binary artifact out of it. But this option has rather strict limitations:
Overall this option does not look promising, it has lots of limitations and a fairly complicated setup.
Gradle pluginAnother alternative is to use a Gradle plugin (written by the author of this article). It helps to fetch and attach external git repositories as dependencies. For the last 5 years we successfully used the first version of this plugin in our company, and now I’m glad to introduce the second version, with a cleaner DSL and some minor fixes. Let’s check the usage.
In
For Gradle prio 6.x a more verbose declaration is needed, see plugin docs.
In module’s
Now the plugin will take care of downloading (or updating) specified git repo into Key features:
The plugin will resolve and download git repos before Gradle projects (modules) are evaluated, so one of the cool features is that you can move all your build scripts into a separate repo as well and then reuse them by declaring in
Now your shared build scripts are available in all the projects with:
In general this option is similar to git submodules but without most of its issues. There are still some issues worth mentioning:
ConclusionIt is always a good idea to separate and reuse repeatedly used code into a dedicated library project. For public libraries binary artifacts distribution is the most popular and recommended option, while private libraries distribution can be trickier. If you wish to avoid building and distributing binary artifacts within your company then the Gradle plugin presented in this article can be a good alternative. As a side effect it also provides a mechanism to reuse your build scripts logic among several projects.
Android News
Our Engineering Roadmap
By Mark Ng We just completed our engineering road map for our Android apps at Australia Post. Each year we get together and try to decide on what we are going to do from an engineering perspective for the next 12 months. Each team gets to decide on what should be done now, what they want to complete by the end of the year and whats on the horizon for next year.
By
ProAndroidDev -
droidcon News
Tech Showcases, Developer Resources & Partners
EmployerBrandingHeader
jobs.droidcon.com
![]() Latest Android Jobs
Kotlin Weekly
![]() Your weekly dose of Kotlin
ProAndroidDev
![]() Android Tech Blogs, Case Studies and Step-by-Step Coding
Zalando
![]() Meet one of Berlin's top employers
Academy for App Success
![]() Google Play resources tailored for the global droidcon community |
Droidcon is a registered trademark of Mobile Seasons GmbH Copyright © 2020. All rights reserved.