There is an Android application using Grandle for build. It uses a "library" stated in build.gradle file:

dependencies {
    api project(path: ':specialproject.speciallibrary', configuration: 'default')

It is configured in settings.gradle:

include ':specialproject.speciallibrary'
project(':specialproject.speciallibrary').projectDir = new File('../specialprojectlibrary')

Developers currently have the main project and specialprojectlibrary projects side-by-side on their computers. So when they build it, Gradle fetches specialprojectlibrary and builds it when building the main app (APK.

Now, when would like to have GitLab CI/CD for the app. Main app and library app are in separe Git repositories and under separate projects inside a group in GitLab.

After creating CI/CD it occured it throws error:

FAILURE: Build failed with an exception.

* What went wrong:
Could not determine the dependencies of task ':something:xyz'.
> Could not resolve all task dependencies for configuration ':something:xyz'.
   > **Could not resolve project :specialproject.speciallibrary.**
     Required by:
         project :mainproject
      > Project :mainproject declares a dependency from configuration 'api' to configuration 'default' which is not declared in the descriptor for project :specialproject.speciallibrary.

I assume it is because it canon CI/CD Gradle of the main app does not have access to library code under .//specialprojectlibrary.

So my question is:

How to copy library source code from other Git repo to an Android Gradle application GitLab build process?

1 Answer 1


What you need is not to checkout both projects side by side, but to add the library as a Git submodule in your application repository.

Then set up GitLab CI to checkout submodules before build.

This will not only make your CI work, but as an added benefit each commit from application repository will reference a specific commit from library repository, so nobody will have to remember what commit to checkout in library repository to ensure the application builds correctly.


To be clear, I'm not saying that composite builds (which is a proper name for your setup) are always bad, but I believe that they should be used for optional dependencies (like JetBrains did in their kotlin-native repository) or when developers need need to have an option of replacing dependency norally pulled from some Maven repository with locally build version (eg. to test if their app works with some changes in the library before submitting pull/merge request for the library) and not for everyday use.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.